专利汇可以提供ORDER MANAGEMENT SYSTEM AND METHOD FOR LIMITED COUNTERPART TRANSACTIONS专利检索,专利查询,专利分析的服务。并且The present invention provides a computer system for managing limited counterpart transaction orders for products or services, in particular with a ceiling price, comprising: —a source of information indexing the available products or services and explanatory variables for these products or services, as well as time related counterpart information for these products or services, —an automatic classification engine adapted to gather products or services by classes of counterpart evolution, from historical counterpart data, and to attribute to each class a set of explanatory variables and an evolution behavior, —a client interface for inputting orders on given products and services defined by explanatory variable values, with a limit counterpart value, —a class allocation engine for allocating an inputted order to at least one evolution class depending on the explanatory variable values of the order, and —an indicator computation engine capable of computing a success probability indicator for an input order, combining the value of the limit counterpart value of the order with data of the evolution class(es) to which it is allocated, —means for providing to said client interface computed values of said success probability indicator, and —a matching engine to match offers and counterpart offers to convert orders into transactions when counterpart offers reach counterpart limit values of orders.,下面是ORDER MANAGEMENT SYSTEM AND METHOD FOR LIMITED COUNTERPART TRANSACTIONS专利的具体信息内容。
The present invention relates to a system to be implemented in a computerized environment for defining, recording and executing maximum price purchase orders for products or services.
In most common selling processes, in particular on the Internet, sellers define the prices of the goods proposed for sale (products or services), and buyers have to take into account the offer diversity, and assess the offer according to their own criteria. This analysis is both time-consuming and complex.
When dealing with products or services whose prices significantly change during the sale period, certain processes exist that allow the buyer to follow the price and be informed about potential changes. In particular, a buyer may be informed when the price reaches a predefined target value. In this specific case, the buyer is not bound to purchase the product or service but, should he want to purchase it, he needs to act quickly and to make the purchase while the cost corresponds to his expectation.
Another known system consists in grouping conditional purchase offers in a system managed by buyers. In such a system, the product or service is automatically sold to a buyer if the predefined maximum price of the conditional offer is reached.
For instance, on the stock exchange markets, limited purchase orders are well known and are widely used in transaction platforms.
Another example can be found in the travel domain: in certain sales platforms a system driven by buyers has already been implemented which aims at collecting conditional purchase offers to purchase flight tickets, hotel nights, car rentals, etc.
The Priceline company has developed such systems.
However existing conditional purchase offer systems provide very little information to help customers fix their ceiling or maximum purchase prices, making the use of such systems difficult for buyers who do not have sufficient experience or market knowledge to determine an appropriate ceiling price.
Moreover the description of the product or service being sold is most of the time unclear, which makes the definition of a ceiling price even harder.
Thus because of a lack of both information and support, many buyers define too low maximum prices leading to a failure of their offers.
The invention presented here aims at compensating part or the totally of the technical state of the art limitations.
The present invention aims at alleviating all or part of the prior art limitations.
The invention presented here aims at providing a system having a least one of the following functionalities:
The present invention thus provides according to a first aspect a computer system for managing limited counterpart transaction orders for products or services, in particular with a ceiling price, comprising:
Preferred but non-limiting aspects of this system are the following features, taken individually or in any combinations that the skilled person will consider as compatible from his general knowledge:
According to a second aspect, the present invention provides a computer-implemented method for managing limited counterpart transaction orders for products or services, in particular with a ceiling price, comprising the following steps:
Preferred but non-limiting aspects of this method are the following features, taken individually or in any combinations that the skilled person will consider as compatible from his general knowledge:
Other aspects, aims and advantages of the present invention will be better understood from the following detailed description of preferred embodiments, given by way of non-limiting examples and made with reference to the appended drawings in which:
The invention is implemented in a computerized platform dedicated to provide the definition, the storage and the execution of counterpart threshold transaction orders, in particular of purchase orders at limited prices, as well as the definition of execution priorities between different purchase orders.
According to this invention, a success probability indicator SPI for an order with a given maximum price is generated and proposed to the user so as to help him/her making a decision.
Another aspect includes the presentation to third parties, in particular to sellers, of the current purchase order list for products or services, in order to facilitate the execution of a transaction for a given product or service by adjusting the selling price.
In the following description given by way of example to illustrate the invention, a system particularly well suited to purchasing and selling flight tickets will be described. This invention may however be used for other products or services in a context of price vs. time evolution.
Referring first to
The client or user interface, shown as Front-End in
By using a client user interface UC, usually a web interface and appropriate input devices (keyboard, mouse, etc.), the buyer is able to generate product or service purchase orders on a sales platform thanks to the following services:
In the system of the invention, a buyer can generate several purchase orders and create links between them. Thanks to such links, if a purchase order is successful, the other ones are automatically canceled. Besides, the user can manually modify or cancel a purchase order whenever he wants, as long as it is not successful.
Thus, a purchase order is valid as soon as it is triggered by the buyer and until it is canceled, manually or automatically, or until the selling period of the product or service has expired.
This domain shown as Back-End in
The back-end system is made of two units that widely use the software MapReduce (MR) (see e.g. http//en.wikpedia.org/wiki/MapReduce), and that are organized as follows:
These indicators computed (or “reduced”) by the environment MapReduce, as well as the class information created by the FDT module, are stored in a flight database (F-DB) that is handled by the server domain. These data are used to estimate the success probability indicator (SPI) of a given purchase order. Their availability allows ensuring a near real-time calculation of the indicator.
This domain shown as “Server” in
It comprises the following elements:
For instance, assuming that there are a number of flight ticket purchase orders as follows:
order 1: 4 seats at 220, leading to a total amount of 880,
order 2: 6 seats at 200, leading to a total amount of 1200, and that suddenly the public price decreases from 240 to 200.
In this case, the platform may choose to provide in priority the order 2 which total is higher than the order 1 (1200>880). Of course, other priority rules based on other order parameters (unit price, order date, etc. . . . ) may be defined and implemented.
Thus the option engine OE is a module of the invention that manages the purchase order lists and their execution as soon as the purchase terms are fulfilled. In practice, the option engine runs requests periodically (for instance three times a day for a flight tickets application) to provider or retailer servers to get the current prices of products or services present in the purchase order list. When a product or service current price equals or is lower than an order maximum or ceiling price for the same product or service, the transaction is automatically performed, and the bank account of the buyer is automatically debited by procedures known per se.
In a preferred embodiment of the invention, the option engine OE uses a cache that allows restricting the number of requests done to a provider (e.g. a GDS). In fact, if the selling price returned from by a request to satisfy an order is higher than the purchase prices of other orders in the list, it is useless to make this request another time for said other orders. On the other hand, if the selling price of a given order allows its execution, it is potentially useful to try to generate equivalent orders one after the other, so as to take advantage of a potential price decrease as fast as possible. Thus, the system orders the orders belonging to a same flight set for a same journey one after the other in the database C-DB. The option engine OE cache is interfaced with the flight data treatment (FDT), via the option engine itself, so that the indicators computed by the FDT module may be updated accordingly with the current prices.
The indicator SPI is computed and displayed in near real-time when a buyer configures his purchase order. Given the extremely large amount of data to be processed, this near real-time calculation and display is a technical problem for the skilled person and one aspect of the invention is a solution to this technical problem.
The “near real-time” performance is due to the fact that it is necessary to at least apply a request to the flight database F-DB and make the estimation in the F-server: the display to the user is not immediate because of the transmission duration of both the request and the answer; nevertheless, these durations may be extremely short.
The main steps for allowing near real-time performance are the following:
The above process is illustrated in FIG. 1bis. Indicator SPI is also available for the buyer during the whole purchase order duration validity, and its variations may be automatically transmitted to the buyer.
It can also be provided that when the indicator value SPI is too low, the platform automatically advises the buyer to purchase the product as soon as possible or to modify the criteria of his order, so as to avoid generating (and paying for) requests to the GDS that have almost no chance to succeed. There is here another advantage of computing a SPI indicator, i.e. avoiding to manage orders that have no (or almost no) chances to succeed.
As explained in the preceding section, the success probability indicator SPI is computed based on allocation of one or several counterpart value evolution classes to an order, based on the explanatory variables of said order. This computation uses the following information:
1) the upstream information about the product or service, i.e. the main characteristics of a product or service selected by the user are clearly known; for instance, in the flight tickets specific case, the principal features are the carrier, the schedule of the considered flight, the flight number, and the interval between the order date and the flight date;
2) the price proposed by the seller for purchasing the product or service: this price may be the one effectively inputted by the buyer, or a price suggested by the sales platform;
3) the knowledge of the past price evolution for a similar product or service: the price history given for a long period (in months or years) is known, as well as certain statistical data such as the average price, the median price, the minimum price; this past knowledge is relevant so as to obtain a good estimation of indicator SPI, as detailed in the following;
4) the price trend of the product or service in the recent past: the recent price evolution, as for instance the price evolution over the past month for a specific flight, is also taken into account; this information allows, firstly, to calibrate a probability estimation algorithm, and secondly, to update this estimation during the purchase order validity period; even though it is not essential to the indicator calculation, this information is taken into account when available.
The indicator is assessed thanks to an algorithm designed to combine these data so as to predict as reliably as possible the success probability of a given purchase order.
This algorithm will now be explained in detail.
Firstly, given the complexity of the problem considered here, involving a huge number of variables (carriers, destinations, dates, etc.) and a large amount of data, it is necessary to simplify the problem.
This is done by clustering the data in a relevant way. This simplification is performed offline, meaning that it is done systematically and before being useful to a given buyer by the back-end, so as to make sure that the indicator is given to the buyer in near real-time.
Thus a number of price evolution classes are first created in the system. Then all price evolutions are assigned to a given class selected among the different classes.
The classes are based on an a priori knowledge of a typical price evolution, and are defined empirically. For instance, there can be created a class of strictly increasing prices as a function of time, a class of increasing then decreasing prices as a function of time, etc.
In a preferred embodiment, a low-pass filter is applied to the data (for example, by doing a sliding mean-value computation using a time width of several days). The price data vector Pi (as a function of time) may then be expressed as:
Pi=Xi+Vi
where Xi is the price evolution trend (i.e. the result of the low-pass filtering) and Vi the price volatility.
The price volatility contains the range in which the prices vary and the variation frequency for each short period (typically, several days). The processing that will be performed on this volatility Vi is described in the following.
The affectation of a given price trend to a class (for instance classes such as increasing trend, decreasing trend, increasing then decreasing trend, etc.) is a well-known problem in the classification process in machine learning.
It should be underlined here that frequently, part of the price information is missing when collecting data flights. Thus, it is important for the chosen classification to be robust to missing data.
Hence, in a preferred embodiment of the invention described in the following, it is suggested to use a K-means clustering algorithm. Nevertheless, it is important to mention that other well-known automatic classification algorithms may be used. For instance, the support vector machine algorithms (SVM), or latent class model based algorithms are particularly well suited. Besides, it is also possible to use a fuzzy logic implementation of these algorithms, according to which an element is classified in a cluster according to a given probability, the probability sum over the clusters equaling to 1.
Referring to
a) given a set of m known observations (X1, X2, . . . , Xm), which are low-pass filtered, and where each observation is a vector of real prices, the automatic clustering, here performed by using K-means, allows, according to a well-known procedure, classifying the m observations in n sets, or classes (with n<=m), so as to minimize the sum of the distances between the vectors in a given set. This first step divides the observation space S as follows:
This clustering is applied to the whole set of past price vectors (learning data). These classes correspond to the most probable price evolution curves as a function of time (i.e. trends) that are named Ck, with 1<=k<=n.
It is necessary to normalize the trend information to make sure that the classification is properly performed. This normalization is done as a function of the price information of a given flight (minimum price, mean price, and median price for example).
Moreover, a price observation Pi taken randomly is always related to a set of explanatory variables. When dealing with flight tickets, for instance, such explanatory variables include the flight carrier, a number of date features (e.g., end of week, holidays, middle of week, etc.), the flight duration, the departure and arrival airports, etc.). The number and description of explanatory variables are predefined when designing the system, depending on the application, and, of course, may vary significantly from an application to another.
Thanks to the price data clustering, the explanatory variables are also gathered. For instance, a given flight of a given company at a given date will be allocated to a given cluster. The explanatory variables that are not used in the class discrimination are not considered here, because they do not provide useful information in the process. The other ones are, of course, considered. This gathering process according to explanatory variables can be optionally automated using methods such as a Correspondence Analysis (CA) (see https://en.wikipedia.org/wiki/Correspondence_analysis) or other comparable methods. The first step for the application of the CA method is the creation of the Contingency Matrix having in columns the explanatory variables, and in lines the indexes of the clusters (from the k-means classification for instance), each element of the matrix thus being the number of price evolutions belonging to a given cluster and corresponding to the given explanatory variable. The processing of the Contingency Matrix allows defining the links between explanatory variables and clusters.
Similarly to the classification applied to the (filtered) trend information Xi, a classification can be optionally implemented for the volatility Vi. In a preferred embodiment of the invention, a K-means clustering is used again, even if other automatic classification algorithms could fit here as well. This classification cannot directly be applied to the signal Vi, for which a least-square classification would have no sense. To perform the classification, the signal Vi is subdivided in several periods (typically, a dozen of days) and the variance of Vi is estimated on each period. Thus Vi is associated to a set {Di,1 . . . Di,p} where p is the number of periods and Di,p is the volatility variance over the period p. The classification is thus performed on these variance sets.
Similarly to the trends, the explanatory variables can optionally be clustered according to volatility (this cluster is most of the times different from the cluster obtained using the trends).
b) Considering a new observation, this new observation is partial by nature because the system is not aware of the whole price sets as a function of time (it is reminded here that the aim precisely is to predict the future behavior of the prices). From the explanatory variables of the observation, the observation may be assigned to a trend class or a set of trend classes. Similarly, the observation may optionally be assigned to a set of volatility classes. And given the features of these classes, it is possible to estimate the probability that the price reaches the lower threshold price (ceiling price) defined by the customer. Pi,k is defined as the probability that an element of the explanatory variable i belongs to the class k. Pi,k is estimated as follows:
The way indicator SPI is computed will now be described in greater detail. For simplicity and clarity, the volatility will not be considered.
Let us consider an explanatory variable i (for instance, a given company), and that a limit price π, valid between the dates di and df (order initial date and order final date), has been provided. Idi,df(Ck≦π) is the indicator function such that Idi,df≦π)=1 if curve Ck goes through a value lower than t in the date range from di to df, and Idi,df≦π)=0 otherwise.
The success probability indicator SPI, for the price π, given the explanatory variable I, is expressed as:
This formula can easily be generalized to the case of a larger number of explanatory variables.
Similarly, volatility may be taken into account by taking advantage of the link with the explanatory variables. Given the probability of belonging to a volatility class, the volatility variance may be estimated for each period. A centered Gaussian random variable which variance equals the estimated variance is added to Ck values: the SPI indicator is then computed as the probability that this value is lower than π. This division between the trend and the volatility is a particular feature of the invention. It expresses the fact that, depending on the performed observations, the price trend is a company's strategic choice, whereas the volatility reflects an occupancy rate feature. This feature is not linked to the trend. Thus, it is relevant to consider it separately.
Up to now, the success probability indicator is computed a priori, i.e. without using any current price observation data (the method only used explanatory variables).
c) Let us now assume that the system knows part of the price evolution, or needs to update the indicator calculation during the purchase order validity period that corresponds to the observation (in the present architecture, this observation comes from the option engine OE cache). This observation, even partially known, may be assigned to a certain cluster by computing a distance between the observation and the most probable price evolution patterns Ck (the trends). Depending on the amount of known information, the system combines an a priori allocation (via the explanatory variables) and an a priori distance allocation, weighted if possible. The weighting takes in consideration the amount of known information. This amount depends on the current date with respect to the beginning and ending dates of the order.
Let us consider the following hypothesis:
The success probability indicator SPI can then be computed by the following formula (1) (the volatility is not taken into account here for the sake of simplicity and clarity).
In the above formula, the adopted weighting is a function of the current date: when the current date is close to the initial date, the indicator SPI is computed by mainly referring to the explanatory variables; when the current date is close to the final date, the SPI is computed by mainly referring to the observations.
Finally, the recent price history may be used to regularly update (in the back-end) the cluster definition that may sometimes lead to a cluster adjustment.
This approach according to the invention offers several advantages:
In a preferred but non-limiting embodiment, the system comprises a feature that aims at presenting certain conditional purchase order lists to third parties, i.e. product or service sellers or retailers. These lists are made of customer database C-DB extracts. The aim of this presentation is to inform the sellers or retailers about the prices that the buyers are willing to pay to buy their products or services, and thus to encourage them to low their prices, immediately and automatically, to favor transactions.
More precisely, the purchase order details may be very useful to a seller, allowing him to modify (manually or automatically, depending on the presented list content) the prices of the excess product or service that he may have. Thus the seller is aware of the price he may sell a given amount of transactions, and an automatic program can set up the selling price to reach a given sales target, and possibly to fulfill all the considered active product or service orders. For instance, if we consider the case where the seller is aware of the fact that there is, for a given product, a purchase order with a ceiling price of 200 whereas the current price is 220, an automatic program may be designed to occasionally decrease the price at 200 to fulfill the order, whereas the price reduction to sell unsold products would have been higher without this order knowledge. Finally, the knowledge of the purchase order details may allow a seller to define his sale policy. According to the example of paragraph 2.3, the seller would favor the order 1 so as to sell at a higher unit price, depending on the product or service request he is the only one to dispose.
There are two modes to present the purchase order list: the push mode and the pull mode.
The sales platform allows to sellers or retailers, connected via a login/password combination, to have access to a dedicated area in which a seller or a retailer can search and check active purchase order details.
Each seller or retailer owns a dedicated area, and can only have access to the purchase orders related to his own products or services, and not his competitor's ones.
For instance, a sales manager of a airline company A has only access to the purchase orders of his own company's flights, and not the purchase orders of competitor's company B or C.
The sales platform is capable of automatically providing purchase order details to various sellers or retailers. For instance, an order report is daily released for each seller, with a list and a detail of active orders concerning products or services provided by the considered seller.
Once the sellers have access to purchase order details, they may carry out certain transactions on their unsold or difficult-to-sell products or services, by decreasing their selling prices following two different mechanisms:
After checking the purchase order prices for the products or services he offers, an online store can decrease the “public” price or “official” price for certain products or services that are difficult to sell. Given the fact that the sales platform regularly checks the “public” prices of the sellers and retailers, the considered products or services will be sold as soon as their selling prices decrease up to the purchase order prices.
For example, considering a airline company A that has difficulties in selling certain seats at 550 for a given flight, after determining that there is a purchase order at a ceiling price of 500, the airline company A can low (manually or via a decision engine) its public price to 500. The platform will automatically buy the ticket at this price, because public prices are regularly checked.
Certain sellers or retailers may have some difficulties to low their public price because all the buyers can have access to the public price decrease, and all the competitors can also decide to low their own prices, leading to an economically harmful price war.
Certain sellers may thus choose to sell their products or services at a lower price in certain distribution channels, thus applying a “private” price that is negotiated between the seller and its distributor.
After checking the purchase order price of his product or service, a seller can thus decrease the “private” price of certain products or services that are unsold on sales platform. If this decrease reached the purchase order ceiling price, the seller makes sure that the selling is processed immediately and automatically on the platform.
In the previous example, the airline company A agrees to decrease the “private” price to 500 on the sales platform, whereas its “public” price remains at 550. Nevertheless, the sale is concluded at 500 immediately and automatically.
It should be noted here that the purchase order lists can be provided to sellers for a counterpart (e.g. a financial counterpart) to the extent that it is able to increase the seller's profitability.
The main advantages of the invention system are the following:
a) the system proceeds automatically and immediately: As soon as the seller agrees on the purchase order price, the transaction is concluded automatically and immediately on the sales platform;
b) the seller's agreement on the purchase order price is not public, and the price is considered as a “private” price; in this way, the “public” or “official” product or service price is not changed;
c) the system is profitable for the sellers; in fact, the sellers are able to know the price at which they may sell their unsold or difficult to sell products or services. Hence, they can minimize the decrease of their prices to simply satisfy the existing price orders.
In the particular case of flight tickets purchase, the buyer can select precisely, besides the departure and arrival airports, the range of dates and the maximum price, a maximum number of flights to include in his order. The success probability indicator is computed and displayed on the customer's screen device in near real-time, to inform the buyer of the probability that at least one of his selected purchase order will succeed.
To implement the success probability indicator SPI, the first step of the process deals with defining the different classes for each route (i.e. flight between two cities), based on the past flight price history observation. The price observations are grouped in a specific database and are linked to explanatory variables (the carrier, the departure and arrival dates, the schedule) as shown in
Each price observation is stored in a database and the five observations x1, x2, x3, x4 and x5 lead to the price curves as depicted in
Given the price data vector equation Pi=Xi+Vi, the algorithm processes each price observation to determine the following features:
Thus the algorithmic process assigns to each class a trend linked to a volatility for a set of explanatory variables specific to the considered class.
If we consider again the previous example, the price observations x1, x2, x3, x4 and x5 are assigned to a class S1, which trend is given in
The explanatory variables linked to this class S1 gather the significant features for this class as shown, for example, in
When a buyer selects certain flights and includes them in a purchase order, each flight is automatically identified by its main explanatory variables. For instance, a Paris-Madrid flight is defined as shown in
In the class database for each flight, a program searches the trend classes the closest to the explanatory variables. It is reminded here that several classes may be found, and a weighting is then performed according to the density of the explanatory variable in each class found.
In the price history observations database, the recent past prices for the considered flight are extracted. If the data are sufficiently extensive, the past prices observation may be exploited. For instance, the recent price observation may be depicted as shown in
This observation is then processed to obtain the trend and the volatility as described previously. The trend is illustrated in
In the present example, the class S1 is identified by the explanatory variables and by the recent prices observation trend and volatility.
The price evolution for the considered flight may then be predicted, and the success probability indicator SPI may be computed. In the present example, at D-42 (42 days) before departure, the current price is of 270. The prediction given by the S1 class is a horizontal trend associated to a relevant volatility in a price range between 230 and 270. The success probability indicator is then high for a purchase order with a ceiling price higher than 230, and low for a purchase order with a ceiling price lower than 230.
In the particular case of hotel stay purchase, the buyer can select precisely the hotels to be included in the purchase order, the dates, and a ceiling price. The success probability indicator is computed and displayed on the customer's screen device in near real-time, to inform the buyer of the probability that at least one of his selected purchase order will succeed.
7.1 CLASS definition
To implement the success probability indicator SPI, the first step of the process deals with defining the different classes for each city, based on the past price history observation. The price observations are grouped in a specific database and are linked to explanatory variables (the hotel reference, the arrival and departure dates, the room type, etc.) as shown in
Each price observation is stored in a database and allows modeling a price curve, as depicted by way of example in
The algorithmic process outputs a number of classes that are determined by the combination of a specific trend linked to a price volatility and to a set of explanatory variables.
Considering again the aforementioned example, the price observations x1, x2, x3 are assigned to two classes S1 and S2, which trends are given in
The explanatory variables linked to these classes S1 and S2 gather the significant features as shown, for example, in
When a buyer selects a number of hotels and includes them in a purchase order, each hotel is automatically identified by its main explanatory variables. For instance, a hotel is defined as shown in
In the class database for each city, a program searches the trend classes the closest to the explanatory variables. In this program, several classes may be found, which are sorted by priority (the first being the closest class). In this example, the class S2 is identified by its explanatory variables.
In the price history observations database, the recent past prices of the considered hotel are extracted. If the data are sufficiently extensive, the past prices observation may be exploited. For instance, the recent price observation may be depicted as shown in
The success probability indicator SPI may be then computed by using the above formula that takes into account a weighting between the class identified by using the recent prices, and the one identified thanks to the explanatory variables, as follows:
The price evolution for the considered flight can then be predicted, and the success probability indicator SPI may be computed. In the present example, at D-45 before departure, the current price is of 300. The prediction given by the S1 class is a horizontal trend C1 associated to a relevant volatility in a price range between 250 and 350. The prediction given by the S2 class is a horizontal trend C2 associated to a relevant volatility in a price range between 175 and 225.
The success probability indicator is computed in the following way, considering a price observation over 15 days, and 60 days before departure:
Yet:
for π<250,
for π>250,
for π<175,
for π>175,
Therefore:
for π<175, IPS=0
for 175<π<250, IPS=15/60=25%
for π>250, IPS=100° A
Of course, the present invention is not limited to the embodiments described and illustrated herein, and the skilled person will be able to bring any improvements, variants, or modifications with his/her general knowledge in the art.
In particular:
标题 | 发布/更新时间 | 阅读量 |
---|---|---|
一种企业管理系统 | 2020-05-13 | 628 |
交易以外币计价的证券的方法和系统 | 2020-05-25 | 216 |
一种基于互联网的一站式区域医用耗材招采供管理系统 | 2020-05-08 | 821 |
数字资产交易所盘面监测方法、装置及系统 | 2020-05-11 | 79 |
Method and apparatus for monitoring and evaluating limit order trading | 2020-05-20 | 440 |
金融商品取引管理装置、プログラム | 2020-05-14 | 405 |
金融商品取引管理装置、プログラム | 2020-05-17 | 1022 |
IDEAL LATENCY FLOOR | 2020-05-13 | 801 |
SYSTEMS AND METHODS FOR OBTAINING AND EXECUTING COMPUTER CODE SPECIFIED BY CODE ORDERS IN AN ELECTRONIC TRADING VENUE | 2020-05-15 | 742 |
IDEAL LATENCY FLOOR | 2020-05-16 | 121 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台,是提供专利分析,专利查询,专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据,免费查、免费专利分析。
专利汇分析报告产品可以对行业情报数据进行梳理分析,涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度,系统通过AI智能系统对图表进行解读,只需1分钟,一键生成行业专利分析报告。