U.S. patent application number 09/863735 was filed with the patent office on 2002-01-10 for server, information communication terminal, product sale management method, and storage medium and program transmission apparatus therefor.
Invention is credited to Seki, Naishin, Tai, Hideki.
Application Number | 20020004751 09/863735 |
Document ID | / |
Family ID | 18660315 |
Filed Date | 2002-01-10 |
United States Patent
Application |
20020004751 |
Kind Code |
A1 |
Seki, Naishin ; et
al. |
January 10, 2002 |
Server, information communication terminal, product sale management
method, and storage medium and program transmission apparatus
therefor
Abstract
A product retail sales management server for managing the retail
sales of a product across a communication network comprises: a
retail sales management module for managing the retail sales of the
product; a price update module 13 for dynamically setting the price
of the product in accordance with rules and the retail sales state
of the product and in accordance with the actual retail sales state
of the product when managed by the retail sales management module;
and an acceptance module 11 for, upon the receipt of an information
request via the communication network, furnishing a request
transmission source with the information concerning the product and
the price of the product, set by the price update module at the
time the information request is received.
Inventors: |
Seki, Naishin;
(Yokohama-shi, JP) ; Tai, Hideki; (Yamato-shi,
JP) |
Correspondence
Address: |
Frank Chau
F. CHAU & ASSOCIATES, LLP
Suite 501
1900 Hempstead Turnpike
East Meadow
NY
11554
US
|
Family ID: |
18660315 |
Appl. No.: |
09/863735 |
Filed: |
May 23, 2001 |
Current U.S.
Class: |
705/20 |
Current CPC
Class: |
G06Q 30/0283 20130101;
G06Q 30/0601 20130101; G06Q 30/06 20130101; G06Q 20/201
20130101 |
Class at
Publication: |
705/20 |
International
Class: |
G06F 017/60 |
Foreign Application Data
Date |
Code |
Application Number |
May 25, 2000 |
JP |
2000-155357 |
Claims
What is claimed is:
1. A server for managing the retail sales of a product across a
communication network comprising: retail sales state management
means for managing the retail sales state of said product; price
setting means for dynamically setting the price of said product in
accordance with rules and the retail sales state of said product
and in accordance with the actual retail sales status of said
product when managed by said retail sales state management means;
and product information provision means for, upon the receipt of an
information request via said communication network, furnishing a
request transmission source with the information concerning said
product and said price of said product, set by said price setting
means at the time said information request is received.
2. The server according to claim 1, further comprising: price trend
information provision means for generating, in accordance with said
actual retail sales state of said product, information concerning
trends affecting the changes of said price of said product, and for
furnishing said information to said information request
transmission source.
3. The server according to claim 1, wherein said price setting
means can set a price for said product by using rules, based on
said retail sales state of said product, according to which the
price is increased as the number of product units sold rises or
decreased as the number of product units sold falls.
4. A server for managing the retail sales of a product across a
communication network comprising: retail sales state management
means for managing the retail sales state of said product; and
price setting means for dynamically setting the price of said
product in accordance with rules and the retail sales state of said
product and in accordance with the actual retail sales status of
said product when managed by said retail sales state management
means.
5. A server for charging for and providing digital content via a
communication network comprising: sales state management means, for
managing the sales state of said digital content; price setting
means, for dynamically changing a charge for accessing said digital
content in accordance with rules and the sales state of said
digital content and in accordance with said sales state of said
digital content, which is managed by said sales state management
means; and information provision means for presenting to an
information request transmission source, upon the receipt of an
information request via said communication network, information
concerning said digital content and said charge for accessing said
digital content that is set by said price setting means at the time
said information request is received.
6. The server according to claim 5, further comprising: price trend
information provision means, for generating, in accordance with
said sales state of said digital content, information concerning
trends affecting the changing of said charge for accessing said
digital content and for furnishing said information to said
information request transmission source.
7. The server according to claim 5, wherein said price setting
means sets said charge for accessing said digital content in
accordance with rules and said sales state of said digital content
and according to which said charge for an access is increased when
the number of accesses of said digital content rises or is reduced
when the number of accesses falls.
8. The server according to claim 5, wherein said price setting
means sets said charge for accessing said digital content in
accordance with rules, which is based on said sales state of said
digital content, according to which said charge for an access is
increased when the rank awarded said digital content, which is
consonant with the popularity or the evaluation of said digital
content, is incremented, or said charge for an access is reduced
when said rank awarded said digital content is decremented.
9. A server for charging for and providing a digital content via a
communication network comprising: sales state management means, for
managing the sales state of said digital content; and price setting
means, for dynamically changing a charge for accessing said digital
content in accordance with rules and the sales state of said
digital content and in accordance with said actual sales state of
said digital content, which is managed by said sales state
management means.
10. An information communication terminal, for accessing a product
retail sales management server across a communication network and
for purchasing a product offered by said server, whereby an
information request is issued to said server in order to obtain
information concerning said product and the price of said product;
whereby said information concerning said product and said price of
said product, and information concerning trends affecting the
changes of said price are received after said server has accepted
said information request; and whereby, when a user has examined
said information, as needed, and has determined to purchase said
product, a purchase request to that effect is transmitted to said
server.
11. A product retail sales management method, for managing the
retail sales of a product in accordance with a purchase request
that is issued, via a communication network, by a server connected
thereto, comprising the steps of: managing the retail sales state
of said product; dynamically setting the price of said product in
accordance with rules and the retail sales state of said product
and in accordance with the actual retail sales status of said
product; furnishing information concerning said product upon the
receipt of an information request via said communication network,
and furnishing said price set for said product at the time said
information request is accepted; and accepting a purchase request
for said product that is issued after said information concerning
said product and said price of said product have been provided.
12. The product retail sales management method according to claim
11, further comprising the steps of: generating, upon receipt of
said information request, information concerning trends affecting
the changes of said price of said product in accordance with said
retail sales state of said product, wherein, at said step of
furnishing said information concerning said product and said price
of said product, said information concerning said trends affecting
the changes of said price of said product is also furnished.
13. A product retail sales management method, for managing the
retail sales of a product in accordance with a purchase request
that is issued, via a communication network, by a server connected
thereto, comprising the steps of: managing the retail sales state
of said product; dynamically setting the price of said product in
accordance with rules and the retail sales state of said product
and in accordance with the actual retail sales status of said
product; and furnishing information concerning said product upon
the receipt of an information request via said communication
network, and furnishing said price set for said product at the time
said information request is accepted.
14. A storage medium on which input means of a computer stores a
computer-readable program that permits said computer to perform: a
process for managing the retail sales state of said product; a
process for dynamically setting the price of said product in
accordance with rules and the retail sales state of said product
and in accordance with the actual retail sales status of said
product; a process for furnishing information concerning said
product upon the receipt of an information request via said
communication network, and furnishing said price set for said
product at the time said information request is accepted; and a
process for accepting a purchase request for said product that is
issued after said information concerning said product and said
price of said product have been provided.
15. The storage medium according to claim 14, wherein said program
generates, upon receipt of said information request, information
concerning trends affecting the changes of said price of said
product in accordance with said retail sales state of said product;
and wherein, in said process for furnishing said information
concerning said product and said price of said product, said
program furnishes said information concerning said trends affecting
the changes of said price of said product.
16. A program transmission apparatus comprising: storage means for
storing a program that permits a computer to perform a process for
managing the retail sales state of said product, a process for
dynamically setting the price of said product in accordance with
rules and the retail sales state of said product and in accordance
with the actual retail sales status of said product, a process for
furnishing information concerning said product upon the receipt of
an information request via said communication network, and
furnishing said price set for said product at the time said
information request is accepted, and a process for accepting a
purchase request for said product that is issued after said
information concerning said product and said price of said product
have been provided; and transmission means for reading said program
from said storage means and for transmitting said program.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] The present invention relates to a retail sales management
system for use when products are sold via a communication
network.
[0003] 2. Discussion of Related Art
[0004] Electronic commerce, involving the retail sales of products
and the contracting out of services using communication networks,
such as the Internet, has become a popular and wide spread addition
to the retail sales business field. An intending purchaser, when
availing himself or herself of the conveniences afforded by
electronic commerce, generally selects a desired product, or a
service, by referring to products for sale, or services to be
provided, that are listed on a computer screen, enters his or her
name, address and telephone number, along with a payment method,
and transmits these data to a retailer. This is all that is
required of the purchaser; all other procedures associated with a
purchase are handled by the retailer.
[0005] The price for a product or the charge for a service is
generally set by a retailer. At this time, the retail price is
normally determined by adding a profit margin to the actual
expenses involved in the manufacture of a product, or in the
provision of a service. Further, when determining a price, the
popularity a product enjoys among users, and user product
evaluations may be taken into account.
[0006] There are retailing methods, such as auction sales, where
buyers take the initiative in setting prices. In such a case,
however, since the buyers compete with each other and bid up the
price of a product, the final price paid may far exceed that which
most consumers would regard as appropriate. And since an auction
sale is more appropriate when the number of intending purchasers
exceeds the available supply of a product, it is not suitable for
general trading.
[0007] According to one method whereby the retail price of a
product is dynamically established, for a product such as a
computer program, the employment frequency (the number of
activations, or the employment period) is recorded and measured,
and when a predetermined value is reached, the payment of a charge
is requested. According to another method, when a specific time has
elapsed following the start of a sale, the retail prices of some
subject products are reduced. However, these retailing methods do
not immediately and directly reflect an evaluation such as is
acquired when a product has been tested on the market and has been
compared with other, similar products.
[0008] During the exchange of data across a communication network,
user evaluations of content to be provided may be fed back to an
intending purchaser. For example, the number of times the content
was accessed, or a user evaluation may be supplied as a reference
item to facilitate the selection of content. Or, the content may be
ranked in accordance with its evaluation or employment frequency,
and thereafter presented to an intending purchaser.
[0009] However, content evaluation is merely provided as reference
matter to be considered when a choice is made, and is not used as a
basis for the setting of a price for a product (content).
[0010] As is described above, according to the conventional retail
sales method, when a retailer sets a price for a product or a
charge for a service, a value attributable the popularity of the
product or the service with users, and how they evaluate it may be
added to the price. However, when the popularity of a product or
service or the user evaluation of it fluctuates over time, a great
deal of labor must be devoted to immediately, and frequently,
changing the retail price to reflect marketing realities.
[0011] However, if a price is set each time there is a variation in
the popularity or in the user evaluation of a product or service, a
lower price can be set for an unpopular product or service to
increase its marketing competitiveness, or a higher price can be
set for a popular product or service to increase the net
profit.
[0012] Further, conventionally, when a retailer sets a retail price
while taking into account the popularity or the evaluation of a
product or a service, only the current popularity or evaluation are
taken into consideration when the price is selected. However, if
along with an altered retail price information were provided
concerning trends affecting price changes (e.g., how the price will
subsequently be changed), such information would assist a user in
appropriately timing the purchase of a product or the selection of
a service.
[0013] As is described above, according to the conventional method
for dynamically setting the retail price of a product, the price of
a frequently employed product is increased and the price of a less
frequently employed product is reduced. But the conventional method
can not flexibly assign a new retail price consonant with a change
in the popularity or in the overall user evaluation of a product or
a service.
[0014] It is, therefore, one object of the present invention to
provide a retail sales management system that, consonant with the
level of popularity or the user evaluation of a product or service,
dynamically sets a retail price for a product or a charge for a
service.
SUMMARY OF THE INVENTION
[0015] To achieve the above object, according to the present
invention, a server for managing the retail sales of a product
across a communication network comprises: retail sales state
management means for managing the retail sales state of the
product; price setting means for dynamically setting the price of
the product in accordance with rules and the retail sales state of
the product and in accordance with the actual retail sales status
of the product when managed by the retail sales state management
means; and product information provision means for, upon the
receipt of an information request via the communication network,
furnishing a request transmission source with the information
concerning the product and the price of the product, set by the
price setting means at the time the information request is
received.
[0016] According to the present invention, a product is any item
targeted for business trading (sales) across a communication
network. Therefore, in addition to prices for general goods and
digital content, the present invention can be applied for the
dynamical setting of a charge for a service.
[0017] Further, according to the present invention, a server may
also be provided that does not include the product information
provision means and that dynamically sets retail prices consonant
with the actual retail sales states of products.
[0018] The server further comprises: price trend information
provision means for generating, in accordance with the actual
retail sales state of the product, information concerning trends
affecting the changes of the price of the product, and for
furnishing the information to the information request transmission
source.
[0019] This configuration is preferable because an intending
purchaser of a product can refer to the information concerning
trends affecting the changes of the price of the subject product,
and can acquire an appropriate timing for the purchase of the
product.
[0020] The information concerning the trends affecting the changes
of the price of the product can be arbitrarily set, using content
based on the number of products sold, such as "how much the price
will be increased after how many more products are sold", content
based on a time element, such as "how much the price will be
reduced at what time", or content based on a rank provided in
accordance with the popularity or the user evaluation of a product,
such as "how much the price will be increased (or reduced) when the
rank is incremented (decremented) by one".
[0021] Specifically, a method for setting a price in accordance
with the number of products sold can be employed to increase the
profit provided by a product that is selling well and for providing
a competitive price provided by a product that is not selling well.
For example, the price setting means can set a price for the
product by using rules, based on the retail sales state of the
product, according to which the price is increased as the number of
product units sold rises or decreased as the number of product
units sold falls.
[0022] Furthermore, according to the present invention, a server
for charging for and providing digital content via a communication
network comprises: sales state management means, for managing the
sales state of the digital content; price setting means, for
dynamically changing a charge for accessing the digital content in
accordance with rules and the sales state of the digital content
and in accordance with the sales state of the digital content,
which is managed by the sales state management means; and
information provision means for presenting to an information
request transmission source, upon the receipt of an information
request via the communication network, information concerning the
digital content and the charge for accessing the digital content
that is set by the price setting means at the time the information
request is received.
[0023] A server can be provided that does not include the
information provision means and that dynamically sets the access
charge in accordance with the actual sales state of the digital
content.
[0024] The server further comprises: price trend information
provision means, for generating, in accordance with the sales state
of the digital content, information concerning trends affecting the
changing of the charge for accessing the digital content and for
furnishing the information to the information request transmission
source.
[0025] This configuration is preferable because a user who accesses
and downloads the digital content can refer to the information
concerning the trends affecting the price of the subject product,
and can acquire an appropriate timing for accessing the digital
content.
[0026] As well as for a general product, information concerning
trends associated with the changing of an access charge, such as
the contents based on an access count, the contents based on a time
element, or the contents based on a rank awarded in accordance with
the popularity or the user evaluation of a product, can be
arbitrarily set.
[0027] The price setting means sets the charge for accessing the
digital content in accordance with rules and the sales state of the
digital content and according to which the charge for an access is
increased when the number of accesses of the digital content rises
or is reduced when the number of accesses falls.
[0028] The price setting means sets the charge for accessing the
digital content in accordance with rules, which is based on the
sales state of the digital content, according to which the charge
for an access is increased when the rank awarded the digital
content, which is consonant with the popularity or the evaluation
of the digital content, is incremented, or the charge for an access
is reduced when the rank awarded the digital content is
decremented.
[0029] According to the present invention, an information
communication terminal is provided, for accessing a product retail
sales management server across a communication network and for
purchasing a product offered by the server, whereby an information
request is issued to the server in order to obtain information
concerning the product and the price of the product; whereby the
information concerning the product and the price of the product,
and information concerning trends affecting the changes of the
price are received after the server has accepted the information
request; and whereby, when a user has examined the information, as
needed, and has determined to purchase the product, a purchase
request to that effect is transmitted to the server.
[0030] Further, according to the present invention, a product
retail sales management method, for managing the retail sales of a
product in accordance with a purchase request that is issued, via a
communication network, by a server connected thereto, comprises the
steps of: managing the retail sales state of the product;
dynamically setting the price of the product in accordance with
rules and the retail sales state of the product and in accordance
with the actual retail sales status of the product; and furnishing
information concerning the product upon the receipt of an
information request via the communication network, and furnishing
the price set for the product at the time the information request
is accepted. The product retail sales management method further
comprises, after the step of furnishing the price of the product, a
step of accepting a purchase request for the product that is issued
after the information concerning the product and the price of the
product have been provided.
[0031] The product retail sales management method of the invention
further comprises the steps of: generating, upon receipt of the
information request, information concerning trends affecting the
changes of the price of the product in accordance with the retail
sales state of the product. At the step of furnishing the
information concerning the product and the price of the product,
the information concerning the trends affecting the changes of the
price of the product can also be furnished.
[0032] According to the present invention, a storage medium can be
provided on which reading means of a computer stores a
computer-readable program that permits the computer to perform the
processes that correspond to the steps of the product retail sales
management method.
[0033] In addition, a program transmission apparatus can be
provided that comprises: storage means for storing the program; and
transmission means for reading, from the storage means, and
transmitting the program.
[0034] This configuration is preferable because a computer that
executes the program can perform product retail sales management,
including dynamically setting the price of a product in accordance
with its retail sales state of the product.
BRIEF DESCRIPTION OF THE DRAWINGS:
[0035] FIG. 1 is a diagram for explaining the general configuration
of a retail sales management system according to the
embodiment.
[0036] FIG. 2 is a diagram for explaining the structure of a
product retail sales management server according to the
embodiment.
[0037] FIG. 3 is a diagram showing an example structure for an
initial setup table used for the embodiment.
[0038] FIG. 4 is a diagram showing an example structure for a price
determination policy table used for the embodiment.
[0039] FIG. 5 is a diagram showing an example structure for a
current price table used for the embodiment.
[0040] FIG. 6 is a diagram showing an example structure for a price
trend table used for the embodiment.
[0041] FIG. 7 is a diagram showing an example structure for a
retail sales history table used for the embodiment.
[0042] FIG. 8 is a flowchart for explaining the operation of an
acceptance module according to the embodiment.
[0043] FIG. 9 is a flowchart for explaining the operation of a
retail sales management module according to the embodiment.
[0044] FIG. 10 is a flowchart for explaining the operation of a
price update module according to the embodiment.
[0045] FIG. 11 is a flowchart for explaining the operation of a
price trend update module according to the embodiment.
[0046] FIG. 12 is a diagram showing an example input screen used
for the embodiment.
[0047] FIG. 13 is a diagram showing the state of the input screen
after a predetermined time has elapsed since the state shown in
FIG. 12.
[0048] FIG. 14 is a diagram showing the initial states of the
respective tables for an example operation according to the
embodiment.
[0049] FIG. 15 is a diagram showing tables in which the states of
the contents in FIG. 14 have been changed.
[0050] FIG. 16 is a diagram showing tables in which the states of
the contents in FIGS. 14 and 15 have been changed.
[0051] FIG. 17 is a diagram showing the initial states of the
respective tables for another example operation according to the
embodiment.
[0052] FIG. 18 is a diagram showing tables in which the states of
the contents in FIG. 17 have been changed.
[0053] FIG. 19 is a diagram showing tables in which the states of
the contents in FIGS. 17 and 18 have been changed.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0054] Preferred embodiments of the present invention will now be
described in detail while referring to the accompanying
drawings.
[0055] FIG. 1 is a diagram for explaining the general configuration
of a retail sales management system according to the embodiment. In
this embodiment, the retail sales management system can be used to
provide various products and services; however, to simplify the
explanation, general goods and services are collectively described
as products, and the retail sales of digital content, such as
music, is especially employed as an example. Further, the Internet
is employed as a communication network.
[0056] In FIG. 1, the retail sales management system for this
embodiment is carried out by a product retail sales management
server 10 for the retail sales of products across the Internet. The
product retail sales management server 10 receives a request from a
user terminal 30, a client, returns an input screen file as an
interface, and accepts from the user terminal 30 the entry of data
concerning the purchase of a product.
[0057] In FIG. 1, when the user terminal 30 issues a product
information request (101) to the product retail sales management
server 10, the product retail sales management server 10 returns,
to the user terminal 30, an input screen file (102) in which is
written information concerning the product for sale, and the user
terminal 30 displays an input screen based on the input screen file
(102) that is received from the product retail sales management
server 10. On the input screen, information concerning the product
for sale and the current retail price for the product are
displayed.
[0058] Then, the user designates a desired product by referring to
the input screen, enters necessary information, and uses the user
terminal 30 to transmit a purchase determination command (103) to
the product retail sales management server 10. Upon the receipt of
the command, the product retail sales management server 10 returns,
to the user terminal 30, a notification (104) confirming the
reception of the purchase procedures.
[0059] The product purchase processing is the same as the
electronic commerce processing used to purchase an ordinary product
via the Internet. In this embodiment, it should be noted that,
since the retail price of the product is dynamically set, when the
product information is transmitted as the input screen file (102)
the retail price of the product is defined as the current price.
Therefore, when the product is to be purchased after a specific
time has elapsed since product information was furnished, the
processing for the provision of the latest retail price of the
product can be added. That is, the user terminal 30 transmits a
product purchase request (105) to the product retail sales
management server 10, and receives from the product retail sales
management server 10 the latest retail price (106). If a
predetermined time has elapsed since the product retail sales
management server 10 received the purchase determination command
(103), the server 10, instead of accepting the purchase procedures,
may return the latest retail price (106).
[0060] In this arrangement, the functions of the product retail
sales management server 10 can be performed by a web server, and
the input screen is prepared as a web page. Then, when at the user
terminal 30 data is entered in the web page, the product purchase
procedures are accepted.
[0061] Further, in this case, the user terminal 30 uses a web
browser to display the web page.
[0062] FIG. 2 is a diagram for explaining the configuration of the
product retail sales management server 10. In FIG. 2, an acceptance
module 11 accepts a product information request (101) from the user
terminal 30. A retail sales management module 12 manages the
history of the retail sales of the product. A price update module
13 manages the retail price of the product. And a price trend
update module 14 manages the trends associated with the changing of
the retail price of the product.
[0063] A database 20 is used to manage the product and its sale,
and an initial setup table 21, a price determination policy table
22, a current price table 23, a price trend table 24, a retail
sales history table 25, and a ranking table 26 are stored in the
database 20.
[0064] FIG. 3 is a diagram showing an example structure for the
initial setup table 21.
[0065] Various information for determining the price of a product
is stored in the initial setup table 21. In the example in FIG. 3,
a product ID, a dependency element for determining the retail
price, the lowest price, the highest price and the currency unit
are stored in the initial setup table 21. The dependency element is
used to determine the price of a product and a change in the price.
The number of sales in FIG. 3 indicates that the price will be
changed when a predetermined number of product sales have been
recorded. That is, since digital content, such as music or video
data, is downloaded once every time it is sold, the price is
changed in accordance with the sales count. For a product or a
service other than digital content, the price can be changed in
accordance with the number of units that have been sold or the
number of times the service has been provided. In addition to the
sales count in FIG. 3, the dependency element can be the retail
sale frequency, which indicates the number of retail sales (units)
processed in a specific period of time, or a ranking based on an
arbitrary concept, such as a retail sales ranking or a popularity
ranking based on predetermined data. Since for the sale of music,
there is a web site that provides rankings representative of the
popularity of musical pieces, ranking information obtained by tying
up with the site can be employed as the dependency element.
[0066] The lowest price and the highest price are set so that the
price of the product will not fall below or rise above a specific
value. When a certain product is especially popular and purchase
requests are concentrated on that product, if the number of
purchases is set as the dependency element, the price of the
product will increase endlessly. However, when the price has
increased until it is too high to be appropriate for the product,
the number of purchase requests will fall, and this is not an
acceptable condition for either the seller and the buyers. On the
other hand, when the popularity of a specific product is low and
the no trading history has been accumulated for it, a price whereat
there is neither a loss nor a profit must be set based on the
manufacturing cost of the pertinent product. Therefore, a
reasonable price range should be determined for the product.
However, these data are not requisite, and one or both of the
lowest and the highest prices may not be set as desired by the
seller.
[0067] Since the entry for the currency unit is set while taking
into account the convenience it offers for trading, this is an
arbitrary setting.
[0068] FIG. 4 is a diagram showing an example structure for the
price determination policy table 22.
[0069] In the price determination policy table 22, the policy for
determining the price of a product is set for a corresponding
dependency element in the initial setup table 21. For example, when
the number of retail sales is set as the dependency element in the
initial setup table 21, a retail sales count dependency policy was
set, such as "increase the price by 10 yen when there have been
twenty sales of the product", or "reduce the price by 10 yen when
there have been no sales of the product for 120 minutes".
Similarly, when the ranking is set as the dependency element of the
initial setup table 21, a ranking dependency policy is established,
such as "increase the price by 10 yen when the rank is incremented
by one", or "reduce the price by 10 yen when the rank is
decremented by one". Further, when retail sales frequency is set as
the dependency element for the initial setup table 21, a retail
sales frequency dependency policy is entered, such as "increase the
price by 10 yen when the retail sales frequency (the number of
retail sales (units) handled in a predetermined period) is
increased by 10%" or "reduce the price by 10 yen when the retail
sales frequency is reduced by 20%". It should be noted that the
parameters (the count, the ranking, the retail sales frequency,
etc.) in the policy described above, and the unit for the price
change (10 yen) can be arbitrarily established.
[0070] FIG. 5 is a diagram showing an example arrangement for the
current price table 23.
[0071] The product ID and the current price of the product are
stored in the current price table 23. In addition, the currency
unit for the price is stored as needed, e.g., when a purchase
request originating in a foreign country is accepted via the
Internet.
[0072] FIG. 6 is a diagram showing an example structure for the
price trend table 24.
[0073] A condition for a next price change is stored in the price
trend table 24 consonant with the dependency element in the initial
setup table 21. For example, the number of retail sales is set as
the dependency element in the initial setup table 21, and a
condition such as "increase the price of the product after five
more sales (Rest_C 5)" or "last time the product was sold (Last
Access C)" is set as a parameter until the price is changed.
Further, when the retail sales frequency is set as the dependency
element in the initial setup table 21, a condition such as
"increase the price of the product when it is sold five or more
times a day (Freq_C 5)" is set as a parameter until the price is
changed. In addition, the time condition can be set as a parameter,
and a condition such as "maintain the current price until 12:59 in
the afternoon (Next_T 12:59 PM)" can be designated. The numerical
value for the count, the frequency and the time for each condition
can be arbitrarily set.
[0074] FIG. 7 is a diagram showing an example arrangement for the
retail sales history table 25.
[0075] The retail sales time and the price of the product at that
time are stored in the retail sales history table 25. The total
number of retail sales of the product is also managed in this
table. And in addition, ID information for purchasers of the
product may be stored in order to provide after sale service.
[0076] When the ranking information is set as the dependency
element in the initial setup table 21, a rank (the retail sales
count rank or popularity rank) corresponding to the dependency
element is stored in the ranking table 26. In this embodiment, a
site for obtaining the aggregate for the ranking may be provided
for the product retail sales management server 10 that provides a
product retail service, and unique ranking may be determined. Or,
the information for ranking performed by another web site is
obtained, depending on a product, and may be stored in the ranking
table 26. When the product is music or video, the information is
obtained from the site established to provide rankings for the
popularity of music pieces or films, so that the price of the
product can be set based on more general ranking information.
[0077] The operations of the individual modules will now be
described. First, the operation of the acceptance module 11 will be
explained.
[0078] FIG. 8 is a flowchart for explaining the processing
performed by the acceptance module 11 in FIG. 2. When the
acceptance module 11 receives a product information request (see
101 in FIG. 1) from the user terminal 30 (step 801), the acceptance
module 11 examines the current price table 23 to obtain the current
retail price of the requested product (step 802). Then, the
acceptance module 11 inquires of the price trend update module 14
the trends associated with the changing of the price of the product
(step 803). The acceptance module 11 prepares the input screen for
the purchase of the product in accordance with the current retail
price obtained at step 802 and the information concerning the price
change trends received from the price trend update module 14 at
step 803. And the file for the input screen (see 102 in FIG. 1) is
transmitted to the user terminal 30 (step 804). A detailed
description of the input screen will be given later.
[0079] During this processing, the acceptance module 11 examines
the price trend table 24 to directly obtain information concerning
the price change trends, but also inquires of the price trend
update module 14 the trends associated with the changing of the
price. This is done because since the information for the trends
associated with the changing of the product price varies in
accordance with the retail sales state of the product and the
elapsed time, the user terminal 30 should be provided the latest
information.
[0080] When the user terminal 30 receives the data file for the
input screen, it then displays the input screen. Thereafter, to
purchase a desired product, a user enters data on the input screen
displayed by the user terminal 30, and uses the user terminal 30 to
transmits a purchase determination command (see 103 in FIG. 1). At
this time, since at the least, a specific time will have elapsed
between the time the input screen file was received and the time
the purchase determination command was issued, the retail price of
the product may have changed since the input screen file was
received. In this case, when the product retail sales management
server 10 accepts the purchase determination command (corresponding
to step 801), before finally accepting the purchase request, the
server 10 may perform the processes at steps 802 to 804 and
transmit the latest retail price to the user terminal 30 (see 106
in FIG. 1).
[0081] A script may also be displayed in the input screen file
transmitted to the user terminal 30 in order to request the
periodic transmission of the latest price and the price change
trends, so that for updating, the price and the price change trends
are periodically transmitted by the product retail sales management
server 10.
[0082] The processing performed by the retail sales management
module 12 will now be described.
[0083] FIG. 9 is a flowchart for explaining the processing
performed by the retail sales management module 12.
[0084] The retail sales management module 12 monitors the operation
of the acceptance module 11. When the retail sales management
module 12 detects the receipt by the acceptance module 11 of the
product purchase determination command and the acceptance of the
purchase procedures (step 901), the retail sales management module
12 updates the retail sales history table 25 (step 902). Then, in
order to determine whether the price should be changed for this
retail sale, the retail sales management module 12 calls up the
price update module 13 and shifts the program control to it.
Thereafter, the processing is terminated (step 903).
[0085] The operation of the price update module 13 will now be
described.
[0086] The price update module 13 operates periodically, or in
accordance with a call by the retail sales management module 12,
and updates the current price table 23.
[0087] FIG. 10 is a flowchart for explaining the processing
performed by the price update module 13.
[0088] The price update module 13 is activated when it is called up
by the retail sales management module 12, or when a predetermined
start time is reached (step 1001). Then, a policy PO is obtained
from the price determination policy table 22, and a change
condition C, which is effective until the retail price of the
product is changed, is acquired from the price trend table 24 (step
1002). The information required to determine whether the current
price table 23 must be updated is also acquired in accordance with
the policy PO and the change condition C (step 1003). The
information required for the determination differs, depending on
the definition of the policy PO.
[0089] When the policy PO for changing the price in accordance with
the number of units sold is defined, information concerning the
number of product units sold must be obtained from the retail sales
history table 25 in order to ascertain how many units have been
sold. Further, when the policy PO according to which the price is
changed as time elapses is defined, the current time must be
obtained from the system.
[0090] In this manner, required information is acquired in
accordance with the contents of the policy PO. When all information
that it seems may be used for the determination has been acquired,
only necessary information is employed in accordance with the
contents of the policy PO.
[0091] Then, the obtained information and the policy PO are
employed to determine whether the current price table 23 should be
updated (step 1004). Then, when the policy PO definition is that
the price must be changed in accordance with the number of retail
sales unit, and the number of retail sales unit at which the price
must be changed is reached, it is ascertained that the current
price table 23 must be updated.
[0092] When it is ascertained that an update of the current price
table 23 is necessary, thereafter, a new price based on the policy
PO is calculated, and the price of the product in the current price
table 23 is updated (steps 1005 and 1006).
[0093] When the current price table 23 has been updated in this
manner, or when an update is not required, the price trend update
module 14 is called up and program control is shifted thereto. The
processing is thereafter terminated (step 1007). When the current
price table 23 is updated and the price of the product is changed,
the price trend table 24 must be changed in accordance with the new
price. Even if the current price table 23 need not be updated, a
condition that is effective until the price has been changed may be
altered when the product has been sold or when a predetermined time
has elapsed. Therefore, the price trend update module 14 determines
whether the condition is changed, and if necessary, updates the
price trend table 24.
[0094] The operation of the price trend update module 14 will now
be described.
[0095] FIG. 11 is a flowchart for explaining the processing
performed by the price trend update module 14.
[0096] The price trend update module 14 is activated upon the
receipt of the inquiry from the acceptance module 11 (see step 803
in FIG. 8) or in accordance with the call issued by the price
update module 13 (see step 1007 in FIG. 10) (step 1101). Then, the
price trend update module 14 obtains, from the price determination
policy table 22, the policy PO for determining the retail price of
the product, and acquires from the price trend table 24 the change
condition C that is effective until the retail price of the product
is changed (step 1102).
[0097] In accordance with the policy PO and the change condition C,
the price trend update module 14 also obtains the information
needed to determine whether the price trend table 24 should be
updated (step 1103). The information required for the determination
differs, depending on the definition provided by the policy PO.
[0098] When the policy PO for changing the price in accordance with
the number of retail sale units is defined, the condition "change
the price after several more units have been sold" is changed each
time the product is sold. Therefore, information concerning the
number of retail sales units must be acquired from the retail sales
history table 25. Further, when the policy PO as defined is for the
changing of the price as time elapses, the condition "change the
price several minutes (or several hours or several days) from now",
or the condition "change the price at a specific hour (or on a
specific date)" is changed to reflect each predetermined time.
Therefore, the time information must be obtained from the
system.
[0099] In this manner, required information is acquired in
accordance with the contents of the policy PO. Further, all the
information that it seems may be used for the determination may be
obtained, but only necessary information may be employed in
consonance with the contents of the policy PO.
[0100] The obtained information is employed to determine whether
the updating of the price trend table 24 is required (step 1104).
That is, a check is performed to determine whether the information
obtained at step 1102 satisfies the change condition C obtained
from the price trend table 24. When the information does not
satisfy the condition, e.g., if the policy PO for changing the
price in accordance with the number of retail sales units is
defined and the number of retail sales units is 0, the processing
is terminated without updating the price trend table 24 (step
1105).
[0101] When the information obtained at step 1102 satisfies the
change condition C acquired from the price trend table 24, e.g.,
when the policy PO establishes that a price in accordance with the
number of units purchased and when the number of purchases is equal
to or greater than one, the price trend table 24 is updated in
accordance with the policy PO (steps 1105 and 1106).
[0102] When the price trend update module 14 is activated upon the
receipt of the inquiry from the acceptance module 11, the price
trend update module 14 transmits, to the acceptance module 11, a
response stating whether the price trend table 24 has been changed
and including the results obtained by changing the price trend
table 24 (step 1107).
[0103] As is described above, since the price trend update module
14 is operated in the same way as is the price update module 13,
and is also activated when the acceptance module 11 has received a
request for product information, the latest information can always
be stored in the price trend table 24.
[0104] In this embodiment, the price trend update module 14 has
been activated not only upon the receipt of the inquiry from the
acceptance module 11, but also by being called by the price update
module 13. However, the price trend update module 14 may be
operated separately from the price update module 13. For example,
when the policy for changing the price of the product as time
elapses is defined in the price determination policy table 22,
information concerning the trend associated with the changing of
the price is varied, as needed.
[0105] Therefore, it is preferable that, in order to update the
price trend table 24, the price trend update module 14 be operated
more frequently than the price update module 13.
[0106] FIG. 12 is a diagram showing an example input screen
displayed by the user terminal 30. In an input screen 40, music
provided as digital content is defined as a product, and the price
is to be changed in accordance with the number of purchases (the
number of downloads).
[0107] As is described above, when a product information request is
issued by the user terminal 30 to the product retail sales
management server 10, the acceptance module 11 of the product
retail sales management server 10 prepares the input screen 40, and
transmits the file for the input screen 40 to the user terminal 30.
The user terminal 30 then uses a browser to display the input
screen 40, and waits for the input of data by a user.
[0108] In FIG. 12, the input screen 40 includes a product
information display column 41, for displaying information
concerning a product, a price display column 42, for displaying the
price of the product, a price trend display column 43, for
indicating the trend associated with the changing of the price, and
a purchase button 44, for transmitting a purchase determination
command. In the example in FIG. 12, music pieces 1 to 3, recorded
by a singer A, and music pieces 1 to 3, recorded by a singer B, are
displayed as product information and are presented in the product
information display column 41, while the prices of the individual
music pieces are displayed in the price display column 42. Further,
the number of purchases (the number of downloads) remaining until
the product price is next raised is displayed in the price trend
display column 43. This value, together with a message at the
bottom of the input screen 40, "raise the price 10 yen every 20
downloads", represents the price change trend. That is, the user
understands that when the number of product information downloads
equals the number displayed in the price trend display column 43,
the download count will reach 20 and the price of the product will
be raised 10 yen.
[0109] When the user selects a desired music piece (a product) on
the input screen 40 and clicks on the purchase button 44, the
purchase determination command is transmitted to the product retail
sales management server 10. Further, if needed, when the purchase
button 44 is clicked on, a purchase procedures screen may be
displayed and the user requested to enter his or her name and
address and to select a payment method. When a predetermined time
has elapsed between the time the input screen 40 was displayed and
the purchase button 44 was clicked on, instead of the transmission
of the purchase determination command, a message may be displayed
requesting the provision of the latest information for the price
and the price change trends, and the data on the input screen 40
may be updated.
[0110] FIG. 13 is a diagram showing the state of the input screen
40 when a predetermined time has elapsed since the state shown in
FIG. 12 was acquired.
[0111] In FIG. 13, the prices for the individual music pieces and
the price change trends (information indicating the remaining
download count before the price is raised) are changed. For
example, it is apparent that music piece 1, recorded by singer A,
has been downloaded 15 times, and that the price will be raised
after another five downloads. Similarly, it is apparent that after
the price of the music piece 2, recorded by singer A was raised
five times (the music piece 2 was downloaded 100 (=20.times.5)
times), the music piece 2 was downloaded ten more times, and its
price will be raised to 140 yen after another ten downloads. In
this manner, more profits can be obtained with a popular, good
selling product by raising its price, and a competitive price can
be provided for a poor selling product by reducing its price.
[0112] The input screen 40 shown in FIG. 12 and 13 is merely an
example, and so long as the same data entry is available, the
structure is not limited to the one shown. For example, the
purchase button 44 may not be provided and the screen may be
shifted to a purchase procedure screen by clicking on a desired
music piece. Or, a script may be written in the input screen file,
so that the price of the product or the price change trends can be
automatically updated.
[0113] The information presented in the product information display
column 41 should also be appropriately displayed in accordance with
the kind of product. For example, if the product is not digital
content but an article, an image of the article or an introductory
statement for the article may be provided.
[0114] A specific operation performed for this embodiment will now
be described. FIG. 14 is a diagram showing the initial state of
each table prepared for a predetermined product. Since the price of
a product is changed without depending on the rankings, the ranking
table 26 is not present. It should be noted that in FIG. 14 the
formats shown in FIG. 3 to 7 are not employed for the respective
tables and that only brief listings of the contents are
displayed.
[0115] In FIG. 14, in the initial setup table 21, the number of
units (Deal Count) of the product (Product ID 01) purchased is set
as the dependency element (Dependency.sub.--1). In the price
determination policy table 22, the number of units (Up counter_C)
that must be purchased to raise the price is set at 20, and the
price rise range (Up Range_C) is set at 10 yen. In the current
price table 23, the initial value of the retail price (Price) is
set at 1000 yen. In the price trend table 24, the number of
remaining units that must be purchased before the price rise
(Rest_C) is initially set to 20. The retail sales history table 25
is set to Null because the sale of the product has not yet
begun.
[0116] Assume that one purchaser bought one product (Product ID 01)
at predetermined time (11:00). FIG. 15 is a diagram showing a table
wherein the contents are changed by this purchase.
[0117] In FIG. 15, the retail sales history table 25 records 11:00
(written as T(11:00)) as the purchase time (Purchase Time) of the
product (Product ID 01), and records 1000 yen as the purchase price
(Purchase Price). Accordingly, as is shown in FIG. 10, the price
update module 13 is operated and whether the current price table 23
must be updated is determined. In this example, since the number of
units (Up Counter_C) required to raise the price in the price
determination policy table 22 is set at 20, and the number of
remaining units (Rest_C) before the price is raised in the price
trend table 24 is set at 20, no price change is performed.
[0118] The price trend update module 14 is operated and whether the
price trend table 24 must be updated is determined. But since one
product (Product ID 01) unit has been purchased, the price trend
table 24 is updated, and the number of units remaining before the
price is raised is decremented by one, to 19.
[0119] Assume that a predetermined time has elapsed (11:30) and the
total number of purchased product (Product ID 01) units has reached
20. FIG. 16 is a diagram showing a table in which the contents are
accordingly changed.
[0120] In FIG. 16, the retail sales history table 25 records 11:30
(written as T(11:30)) as the purchase time (Purchase Time) of the
product (Product ID 01), and records 1000 yen as the purchase price
(Purchase Price). Accordingly, as is shown in FIG. 10, the price
update module 13 is operated and whether the current price table 23
must be updated is determined. In this example, since the number of
units purchased reaches 20, that is the number of units (Up
Counter_C) required to raise the price in the price determination
policy table 22, and the number of remaining units (Rest_C) before
the price is raised in the price trend table 24 is reduced to 0.
Thus, the current price table 23 is updated and the retail price of
the product (Product ID 01) is changed. Since the range (Up
Range_C) of the price rise in the Price determination policy table
22 is 10 yen, the retail price (Price) in the current price table
23 is increased 10 yen to 1010 yen. Therefore, the product (Product
ID 01) is thereinafter purchased at 1010 yen.
[0121] The price trend update module 14 is operated and whether the
price trend table 24 need be updated is determined. In this
example, the price trend table 24 is also updated based on the
updating of the current price table 23. Specifically, since this
occurs immediately after the current price table 23 is updated by
the price update module 13 and the new retail price is obtained,
the number of units (Up Counter_C) required to increase the price
in the price determination policy table 22 is again set to 20.
[0122] Another example operation for this embodiment will now be
described.
[0123] FIG. 17 is a diagram showing the initial states of the
tables concerning a predetermined product. In this example, since
the price of the product is changed without depending on its rank,
the ranking table 26 is not present. It should be noted that in
FIG. 14 the formats shown in
[0124] FIG. 3 to 7 are not employed for the respective tables and
the only brief listings of the contents displayed.
[0125] In this example, the price update module 13 and the price
trend update module 14 are activated every ten minutes to determine
whether the current price table 23 and the price trend table 24
must be updated.
[0126] In FIG. 17, in the initial setup table 21, the number of
units (Deal Count) of the product (Product ID 01) that are
purchased is set as the dependency element (Dependency.sub.--1). In
the price determination policy table 22, the number of units (Up
counter_C) that must be purchased to raise the price is set at 20,
and the price rise range (Up Range_C) is set at 10 yen. Further, in
this example, when there have been no product (Product ID 01)
purchases for a predetermined period of time, the retail price of
the product is reduced. Thus, in the price determination policy 22,
the time defined as the price reduction condition (Time Limit_C) is
7200 seconds, and the range of a price reduction (Down Range_C) is
set at 10 yen.
[0127] In the current price table 23, the initial value of the
retail price (Price) is set at 1000 yen. In the price trend table
24, the number of units remaining to be purchased before a price
rise (Rest_C) is initially set to 20. The last access time (Last
Access_C), i.e., the time whereat the count is initially began, is
set at 10:00 (written as T(10:00)). And the retail sales history
table is set to Null because the sale of the product is not yet
begun.
[0128] After 10:00, the product retail sales management server 10
activates the price update module 13 and the price trend update
module 14 every 10 minutes to permit them to determine whether the
updating of the tables is necessary. However, because in each case
the time elapsed since the price trend table 24 was last accessed
(Last Access_C) is less than 7200 seconds, which is the price
reduction condition in the price determination policy table 22,
neither the current price table 23 nor the price trend table 24 are
updated.
[0129] Assume that one purchaser bought one product (Product ID 01)
at a predetermined time (11:00). FIG. 18 is a diagram showing
tables wherein the contents are changed by this purchase.
[0130] In FIG. 18, the retail sales history table 25 records 11:00
(written as T(11:00)) as the purchase time (Purchase Time) of the
product (Product ID 01), and records 1000 yen as the purchase price
(Purchase Price). Accordingly, the price update module 13 is
operated and whether the current price table 23 must be updated is
determined. In this example, since the number of units (Up
Counter_C) required to raise the price in the price determination
policy table 22 is set at 20, and the number of remaining units
(Rest_C) before the price will be raised in the price trend table
24 is set at 20, no price change is performed.
[0131] Thereafter the price trend update module 14 is operated and
whether the price trend table 24 must be updated is determined.
Since one product (Product ID 01) unit has been purchased, the
price trend table 24 is updated, and the number of units remaining
before the price is raised is decremented by one, to 19, and 11:00
(T(11:00)) is set as the last access time (Last Access_C).
[0132] Assume that thereafter the product (Product ID 01) is not
purchased for 7200 seconds (two hours). Then,
(T(Current Time)-Last Access.sub.--C).gtoreq.(Time
Limit.sub.--C)
[0133] is established, and thus, the price update module 13 and the
price trend update module 14 update the current price table 23 and
the price trend table 24. FIG. 19 is a diagram showing the tables
after the contents have been accordingly changed.
[0134] In FIG. 19, first, since the range (Down Range_C) of the
price reduction in the price determination policy table 22 is 10
yen, the retail price (Price) in the current price table 23 is
reduced by 10 yen to 990 yen. Thus, the product (Product ID 01) can
thereafter be purchased at 990 yen.
[0135] Since the current price table 23 has just been updated by
the price update module 13 and a new retail price has just been
obtained, the price trend update module 14 again set to 20, the
number of units (Up Counter_C) that are required to be purchased
for the price in the price determination policy table 22 to be
raised. Further, in order to count the time again, the last access
time (Last Access_C) is set to the current time (written as
T(Current Time)), i.e., 13:00.
[0136] As is described above, the retail price of the product can
be dynamically changed in accordance with the retail sales state of
the product, and an appropriate retail price can be set in
accordance with the reaction of the market.
[0137] As is described above, according to the present invention, a
retail sales management system can be provided that dynamically
sets the retail price for a product or a service in accordance with
the popularity or an evaluation of the product or the service.
[0138] A legend for the symbols is repeated herein for
convenience:
[0139] 10: Product retail sales management server
[0140] 11: Acceptance module
[0141] 12: Retail sales management module
[0142] 13: Price update module
[0143] 14: Price trend update module
[0144] 20: Database
[0145] 21: Initial setup table
[0146] 22: Price determination policy table
[0147] 23: Current price table
[0148] 24: Price trend table
[0149] 25: Retail sales history table
[0150] 26: Ranking table
[0151] 30: User terminal
[0152] 40: Input screen
[0153] Having described embodiments of the invention it is noted
that modifications and variations can be made by persons skilled in
the art in light of the above teachings. It is therefore to be
understood that changes may be made in the particular embodiments
of the invention disclosed which are within the scope and spirit of
the invention as defined by the appended claims. Having thus
described the invention with the details and particularity required
by the patent laws, what is claims and desired protected by Letters
Patent is set for in the appended claims.
* * * * *