This disclosure relates to computer-aided-design software and systems, and more particularly to computer-aided-design software and systems configured to charge for use based on the complexity of parts comprising the design.
Computer software has been developed for automating many design functions, including drawing, creating designs for parts to be manufactured, creating designs for buildings to be built, and designing paths for a movable head of a computer-controlled machine tool. Unfortunately, the relatively high costs of coding and supporting such software may necessitate a price or seat license that is relatively expensive. Such a price barrier may be especially difficult for occasional users to bear. Moreover, it may be difficult to develop or document pass-through software use costs to customers of designers, fabricators, etc.
These and other shortcomings may be addressed by embodiments described herein.
According to an embodiment, a price for using computer-aided design software may be set as a function of the complexity of a design.
According to an embodiment, design software includes an estimator module to estimate the amount of time that would be saved for a human designer by using the design software to assist with creation of the design instead of completing the design without using the software.
According to an embodiment, the estimate is run using the estimator module and presented to the user, and the user is asked if he is willing to pay an amount of money which is calculated based on the amount of time that the estimator module has estimated will be required for a designer to prepare the design without using the specialized design software.
According to an embodiment, the price to be paid by the user is a function of the complexity of the particular job. For example, for a simple job where the amount of time to be saved is small, the price is low. For a complex job where the amount of time to be saved is high, the price is high.
According to an embodiment, the user is given the option to accept the price presented by the software or to reject it. According to embodiments, network communications may be used to enable the specialized design software to be used for the project if the user has agreed to make the specified payment; otherwise, the software will not be usable to assist with the requested design.
Software modules implementing embodiments may be particularly useful where significant mathematical computations are required. Such computations can be performed quickly by the computer. For example, if pieces are to be cut from a material, the process of determining which pieces should be cut from which portion of the material and how the pieces should be nested (e.g., placed beside and within each other) to make the most efficient use of the material can involve many options with geometric complexity that can be quickly solved using geometric mathematics. However, it may be relatively time consuming for a user to make these calculations without specialized software designed for this purpose. Also, for movable heads on a machine tool performing a complex process, one path may be better than another. Such paths may be determined much more quickly using a computer.
Other aspects and embodiments will become apparent in the appended brief description of the drawings, detailed description, figures, and claims.
A numbering convention to facilitate easy understanding by the reader is used herein. Figures are numbered in conventional consecutive order. Specific features are generally indexed consecutively using three or four digit numbers in the order described. The first one or two digits correspond to the figure number in which the feature is first described. Features having similar functionality generally retain their originally assigned number throughout, even though their physical or logical appearance may vary considerably from figure to figure.
There are various processes for computer aided manufacturing that involve cutting pieces from a material. One such category of processes is cutting using a beam or jet such as laser, electron, plasma, water jet, or abrasive water jet. In such applications, the best path to be followed by the beam or jet may be determined more quickly using specialized software. The same applies to other processes involving the motion of a tool-head relative to a work piece, including milling machines, spray painting machines, electrode position machines, electro-discharge machining, wire EDM, machines that build up a part by triggering the polymerization of a liquid polymer (e.g. UV cure), sintering, punch presses, ink jet manufacturing processes, sewing pattern design and manufacture, etc.
One such application, where the amount of time potentially saved by use of specialized software may be significant compared to the amount of time required for drafting without the specialized software; is the determination of an optimized nesting arrangement between parts to be cut from a sheet of material, such as in abrasive jet cutting. According to an embodiment, the shapes of each part to be cut are provided to a computer system in the form of CAD entities, along with a specification of kerf that must be allowed between adjacent cut pieces, quantity of shapes, and dimensions of the raw material to be cut. With this information, specialized nesting software can apply prior art algorithms to test possible layouts of the pieces on the material to be cut to determine an efficient configuration.
According to an embodiment, one adds to such prior art nesting software or other specialized design software a module that prevents it from providing a desired output until authorization has been received. Authorization may, for example, be in the form of an authorization token received across a computer network. One approach may be to transmit and receive the authorization token a secure means that allows the token to be effective without revealing to the user information that would allow the user to simulate the receipt of such a token in the future. Alternatively or additionally, a variable unlock key may substantially prevent a given code value to be used more than once to enable the design software. These and other methods for selectively controlling or enabling the use of computer software are known in the prior art.
According to an embodiment, an estimator module that estimates the amount of time or effort that would be required for the user to create the design without use of the specialized software is included. According to an embodiment, the estimator module may take into account effects such as part or shape complexity, raw stock size constraints, part quantity, and or other effects.
According to an embodiment, a price calculation module applies a pre-determined or dynamically calculated price model to set a use price as a function of the estimated time savings. According to an embodiment, the price calculation module may receive information across a network from the vender of a software system, an electronic bid system, etc.; such that prices or price determination algorithms may be determined dynamically or modified periodically.
According to an embodiment, a user interface module may activate the estimator module and the price determination module and then present to the user a price to be charged if the user wishes to use the software for the particular job presented. If the user responds in the affirmative, the user interface module then communicates with a server run by or for the vendor of the software system to make an electronic charge to an account for the user and, if the charge is authorized, returns a token that, when provided to the module which controls use of the software, allows the software to be used for that job.
According to an embodiment, a server module may update the pricing or price algorithm in the customer pricing module, receive the charge request from the customer, obtain a charge authorization for the account specified by the customer, and return a usage authorization token to the software running on a client computer. The client computer may then responsively allow the specialized design software to be used to create the design.
Proceeding to step 104, an estimator module calculates a processing value. The processing value may be a function of some or all of the design input and may additionally rely on external variables or constants. According to an embodiment, a design computer such as a nesting optimizer may run a final or provisional design optimization, while the number of instructions processed, clock cycles consumed, or other measure of computational complexity is monitored. The measure of computational complexity may then be converted into a value and used to determine a price for using the software. According to another embodiment, actual or abstracted attributes of the design input may be used to drive an algorithm or table look-up that directly or indirectly determines a price.
Attributes of a design that may be used as input to determine a use price include: complexity of parts to nest including: number of corners in a part, number of arcs in a part, number of features in a part (e.g. holes, etc.), number of elements making up a part (e.g., a square would have four elements), curvature, and symmetry; complexity of the nest of parts including: number of parts to nest, number of different parts to nest; dissimilarity of parts, complexity of each part, and complexity of the sheet or sheets to nest; features enabled for the nest including: whether or not to common line cut, whether or not to automatically tab pieces, whether or not to automatically create a tool path sequence, and whether or not to bridge pieces; process constraints; assembly specifications; raw stock specifications; raw stock size or sizes; draft angle requirements; tolerances; surface finish requirements; grain or directionality (also referred to as anisotropy) of the raw material; the need to control grain direction of material in a part; raw stock cost; shape price target; and tool path efficiency target. Some or all of the listed attributes and other non-listed attributes may be used to determine complexity.
Other approaches may be used to determine price. According to embodiments, an output or intermediate value determined for the processing value may be converted into a manual effort equivalent, for example in hours required for manually performing the design task.
Proceeding to step 106, the determined price may be presented to the user to accept or not accept. Such presentation may include a presentation of a price for use of the software. Such a price may be in a currency amount, or alternatively may be in the form of credits such as credits-on-deposit, credits accumulated through rebates or other award-derived accumulations, etc. Additionally, the presentation of step 106 may include a presentation of hours saved, a price-per-hour basis, deductions such as use incentives, quantity rebates, market adjustments, etc. Additional presentation may include display of information intended to urge the user to make a positive purchase decision.
While terms such as “price” and “purchase” are used herein, such terms should be regarded broadly. For example, the “purchased” use of the software may include payment of a license, royalty fee or, alternative forms of consideration. The use of the software may include literal use of the software, access to output from the software, local running of the software, access to the software remotely such as through a browser, use of the software by another user, access to parts manufactured according to output from the software, and other tangible or intangible benefit derived from the software. For example, according to an embodiment, the software may be provided at no cost, and the output data files made usable through “purchased” authorization.
Proceeding to step 204, the user makes a selection of whether or not to accept the price. According to some embodiments, the user may elect not to pay the price, but rather return to block 102 as indicated by the “NO” branch of decision block 204. Return to the design input block 102 may allow the user to modify the design such as by adding additional design elements or specifications, removing a portion of the design elements or reducing specifications, etc. to later return to block 202 and evaluate the marginal cost or savings for various design combinations. In this way, the user may interactively select a portion of design work he wishes the design software to perform with the intent of performing another portion of the design manually. According to some embodiments, the price structure may be set to encourage the user to select all or a large portion of the design to be performed by the software, such as by using variable weighting of processing value. If the user decides to accept the presented price, he may be presented with options and facilities for payment such as by using a third party payment service, an on-line storefront, addition of the price to a material purchase, etc. According to some embodiments, the user may save the design session without making a final software use purchase decision. The user or another party may then review one or several design sessions at a later time (or simultaneously in the case of another party) and make the purchase decision.
Following an affirmative decision and processing of payment in block 204, the program proceeds to block 206 where output of the design is enabled. According to some embodiments, the highest processing value is in the derivation of instructions such as tool paths for computer-controlled machinery. In such cases, step 206 may include making tool path calculations, and/or may include allowing previously calculated tool path descriptions to be released from a secure memory or storage to a user-accessible memory or storage.
Subsequent sessions may further allow a user to add additional design input in step 102, have the price determined for the incremental input in step 202, and be presented with a decision in block 204 of whether to add the additional design input to the previously created output. Such a calculated price may include a premium amount (which may or may not be presented to the user) associated with adding an incremental amount to an existing design.
Proceeding to step 304, if the desired design input is not complete the process loops back to step 102 where additional or modified design input is received. Thus, the loop through steps 102, 302, 304 may provide an interactive design input session with the system providing design feedback as the session proceeds. According to the embodiment, the user is thus allowed to spot and correct layout issues, input errors, etc. prior to being presented with a purchase decision, and also receives feedback on a design as it proceeds. According to some embodiments, such feedback may help to improve a user's time and/or psychological investment in a design and may help to secure a positive purchase decision. Once a design input, or a provisional design input has been completed, the user may respond in the affirmative to a question posed in step 304, or may alternatively make an unprompted choice to proceed to the next phase. The program then proceeds to step 306.
In step 306, the complexity of the software design calculation is determined. As described above, several variable and constant values may be incorporated into the calculation. In one example, the complexity of shapes to be nested in a nesting optimizer is included in variables used to calculate the complexity in step 306. Step 306 may be performed subsequent to the completion of the design input and feedback loop of steps 102, 302, 304. Alternatively, step 306 may represent retrieval of previously determined values. According to an embodiment, the software whose services are offered is operative during the 102, 302, 304 loop. In such a case, step 306 may include monitor and/or retrieval of computer resources consumed during processing. In this way, step 306 may be included within the 102, 302, 304 loop, for example being performed prior to step 302, as the design software performs calculations necessary to present the design in step 302.
Following calculation of the complexity of the design, the process proceeds to step 308, where a savings estimate is performed. The savings may represent the output of a table look-up or algorithm that operates on the output of step 306 to provide an estimate of time saved by avoiding manual processes and/or design entry processes in alternative (e.g., competitive) design software products. As described above, the savings may be included in subsequent presentation to the user. Proceeding to step 310, the estimated savings such as time savings are combined with additional information to calculate a price, and the price is presented to the user. Such additional information may include, for example, hourly rate information that may adjusted to the user's location, the amount of time used during design input, the relative demands on system resources, time-of-day, day-of-the-week, time-of-year, the user's previous experience with the system, the volume of design input previously made by the user, the user's previous rate of accepting charges, the user's payment history, the user's credit score, existence of promotional pricing, additional services purchased or determined likely to be purchased by the user, and other factors.
Proceeding to step 204, the system may receive an election by the user to pay for the services and process payment, following which the system proceeds to step 206, where output is enabled as described elsewhere. Alternatively, the user may elect not to pay for services, upon which the process proceeds to block 312 where it is determined whether the user or the system wishes to terminate the session. A system termination decision may be made, for example, upon reaching a maximum loop count and/or other indication that the user is not likely to make a purchase. If neither the system nor the user elects to terminate, the program returns to step 102 where additional or replacement design input may be received.
As indicated above, one application for the system described herein includes the determination of nesting layouts for nested parts to be cut from a raw stock.
As mentioned above and elsewhere in this document, one approach to determining a processing value is to simply measure the computing resources consumed in processing a design.
Upon making or receiving a terminate decision, the value calculator 606 may terminate a design session and end processing by the input module 602 and nesting optimizer 604. Upon receiving a purchase decision, the value calculator 606 may call a payment processor 608 to process payment for the computing services provided by the nesting optimizer 604.
The payment processor 608 may include an on-line storefront, a third party payment processor, an account debiting resource, etc., and may interact directly with the user (such as through a graphical user interface), through the input module 602 as shown, or may interact with the user through the value calculator as also shown. After payment is received or otherwise processed, the payment processor 608 may inform the value calculator 606, and the value calculator enable the nesting optimizer 604 to continue and output the design. Alternatively, the payment processor 608 may directly interact with the nesting optimizer 604 to enable output. Alternatively the value calculator 606 or the payment processor 608 may interact with a design output module 610 to enable output of the optimized nesting layout and/or tool path determined by the nesting optimizer 604. The design outputter 610 may enable deriving the tool path determination or may receive a previously determined too path. The design outputter 610 may allow output of tool paths to a tool controller and/or may allow output of tool paths and/or nesting design to a user accessible resource such as memory or storage. Alternatively, the design outputter 610 may simply provide decryption of a nesting design and tool path provided by the nesting optimizer 604.
Upon completion of a design output by the nesting optimizer 604 and/or design outputter 610, the respective module may inform the value calculator and/or payment processor to validate completion of the process that had been authorized and/or paid for by the user. According to various embodiments, the user may be presented with a completion message and the message and activity logged. According to some embodiments, the completion of payment processing may be delayed until the nesting optimizer 604 and/or design outputter 610 has informed the value calculator 606 and/or payment processor 608.
The logical connections between modules 602, 604, 606, 608, and 610 shown in
As mentioned above and elsewhere herein, another approach to determining a price for using a computer design resource involves making a calculations based on characteristics of the design input rather than being based on computer resources consumed by the design processor.
While
A computer and network system 801 diagrammatically shown in
A network 820, which may include a LAN, WAN, MAN, the Internet, etc. includes provision for connecting computers 802 to servers and other client devices. One or more shape servers 822 may provide access to a database of shapes 824 that may be retrieved for a design. Alternatively, shapes may be obtained through search through non-specified resources, may be retrieved from local storage 812, or may be designed in a current design session such as a design session performed on a client computer 802. Shapes may be retrieved and specified for inclusion in a design.
A raw stock server 826 may be provided to deliver information about available raw stock. For example, for a manufacturer who cuts successive jobs from a set of raw stocks, the raw stock server may include a database 828 that tracks available raw stock sizes and grades. Such raw stock sizes may, for example, include selvage or other unused portions from earlier jobs or other jobs in queue for fabrication. In such a case, the design software may query raw stock servers 826 and determine optimized use of not only new, nominally sized raw stock, but also raw stock remaining from earlier or other jobs that may otherwise go to waste. A plurality of raw stock servers 826 may be operative to provide raw stock inventory information from a plurality (e.g., a corresponding plurality) of raw stock suppliers.
A transaction server 830 may provide a bank of credits, may operate an on-line store for purchasing credits, etc. The transaction server may further provide a resource for the estimator and pricing modules, thus securing the code running therein and preventing unauthorized modification of estimator and pricing algorithms or table lookups.
After authorization, the design application may output tool control codes to one or more tool controllers 832 programmed to control tools 834 to cut or form designs such as nested shapes. According to an embodiment, the tool may be include a water jet or abrasive jet cutting mechanism. According to embodiments, the tool controller 832 may be integral to or separate from the controlled tool 834.
According to an embodiment, the design application may be enabled to provide an encrypted output that may be uploaded to a network resource such as the transaction server, etc. The encrypted design may then be stored and later enabled for decryption and transmission to a tool controller 832.
Embodiments may be run on an individual computer 802 and may optionally access resources spread across other computers 802 or on networked resources such as servers 822, 826, 830, 836, and tool controller 832, . Programs may be run locally or may be accessed on a server. Various embodiments may be run on peer-to-peer, client-server, host-terminal, or other network environments.
While resources for performing aspects according to embodiments are shown distributed across a network, other combinations may be envisioned. For example, a design application may be accessed on a server 836 by a browser running locally. The application server 836 may similarly provide a shape database, raw stock database, and transaction facility. Alternatively, a complete application having a bank of credits may be loaded and run locally in the client computer 802. Additional credits may then be downloaded as needed from a transaction server. Alternatively, a user agreement may allow a seat to use design software repeatedly without explicit quote and acceptance by the seat. Rather, the transaction server may monitor use and subsequently bill the user for cumulative designs tried and/or completed during a billing cycle. Such billing may be made with customer data added or may be made directly to customers of the user of the client computer 802. The transaction server may additionally accept third party requests for designs and route such designs to subscriber clients 802 for execution of the design, the transaction server then billing the third party for use of the software and, optionally, for fees forwarded by the subscriber. As may be appreciated still other combinations may comprise embodiments.
The preceding overview, brief description of the drawings, and detailed description describe exemplary embodiments according to the present invention in a manner intended to foster ease of understanding by the reader. Other structures, methods, and equivalents may be within the scope of the invention. As such, the scope of the invention described herein shall be limited only by the claims.
This patent application claims priority benefit from and incorporates by reference U.S. Provisional Patent Application Ser. No. 60/763,862; entitled METHOD FOR CHARGING FOR USE OF DESIGN SOFTWARE WITH CUSTOMER OPTION BASED ON COMPLEXITY; invented by Carl Olsen; filed on Jan. 30, 2006.
Number | Date | Country | |
---|---|---|---|
60763862 | Jan 2006 | US |