DETAILED ACTION
Status of Claims
This final Office action is responsive to Applicant's amendment filed 9/2/25. Claims 1, 16 and 17 have been amended. Claims 2-12 have been canceled. Claim 18 has been added. Claims 1 and 13-18 have been considered as follows.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The previously pending rejection of claims 1 and 13-17 under 35 U.S.C. § 101 is not withdrawn in response to Applicant's claim amendments. Examiner submits that while a procurement management system comprising a processor is provided, there is no positive recitation of how the system transforms or changes the nature of the claim into something patent-eligible.
Response to Arguments
Regarding Applicant’s arguments drawn to the rejection of the pending claims under 35 U.S.C. § 101, Examiner respectfully disagrees and reiterates that the claims, even as amended, are not drawn to patent eligible subject matter. First, regarding Applicant’s arguments drawn to specific details of how the automatic step(s) is/are done, Examiner respectfully disagrees. Amendments have been made to include that the purchasable quantity is a maximum quantity that can be purchased, as well as that automatically determining the satisfaction of the distribution condition includes the processor acquiring from the supplier terminal a quantity of the article that can be supplied by each supplier and calculating the purchasable quantity by adding the quantity of articles supplied by the each supplier in the group and comparing the purchasable quantity with the request quantity, as well as a displaying a web page on the user terminal that contains a quantity input field where the user can enter a quantity less than the purchasable quantity and a purchasable quantity field that shows the purchasable quantity stored in the storage medium. First, regarding the amendments drawn to the purchasable quantity is a maximum quantity that can be purchased, Examiner submits that this is merely a clarification as to what the purchasable quantity entails. This does not contribute to specific details regarding how automatic steps are being performed. Next, regarding the amendment drawn to automatically determining the satisfaction of the distribution condition includes the processor acquiring from the supplier terminal a quantity of the article that can be supplied by each supplier and calculating the purchasable quantity by adding the quantity of articles supplied by the each supplier in the group and comparing the purchasable quantity with the request quantity, Examiner submits that this added element describes additional detail regarding the mathematic component of how the distribution condition is satisfied (i.e. by adding quantity of articles supplied by each supplier and comparing the purchasable quantity with the request quantity). This element also does not describe the technological environment that is attributed to the automatic performing of the method steps and in fact is drawn more to the abstract grouping of Mathematical Concepts, i.e., Mathematical Calculations: the act of calculating using mathematical methods to determine a variable or number. Finally, regarding the last element drawn to displaying a web page on the user terminal that contains a quantity input field where the user can enter a quantity less than the purchasable quantity and a purchasable quantity field that shows the purchasable quantity stored in the storage medium, Examiner submits that the displayed web page element is merely an additional element that does not integrate the judicial exception into a practical application: Merely reciting the words “apply it” (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea (see MPEP § 2106.05(f)).
For at least these reasons, these claim limitations, either individually or as an ordered combination, do not amount to significantly more than the abstract idea itself and do not transform the nature of the claim from the judicial exception into a patent-eligible application. Although the invention teaches of a system and computer-readable medium, there is also no physical transformation or improvement to the technology that would be more than the idea of itself. Furthermore, in the current language, the claim is merely implemented or executed using a processor and therefore does not improve upon the technology or functionality of the computer beyond the abstract idea. In other words, Examiner submits that the inventive concept, i.e. an element or combination of elements that is “sufficient to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept (of an abstract idea itself)”, is unable to be determined within the limitations as claimed.
Applicant's arguments with respect to the rejection of the pending claims under 35 U.S.C. § 102 have been considered but are moot in view of the new ground(s) of rejection. Regarding Applicant's argument that the cited references do not teach of all the limitations as amended, Ghaisas et al. (US 2002/0198756 A1, herein Ghaisas) has been brought in, necessitated by amendment, to illustrate this aspect (see claim 1 rejection below).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 and 13-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a patent-ineligible abstract idea without significantly more and are merely requiring generic computer implementation, which fails to transform that abstract idea into a patent-eligible invention. In view of the two-step test regarding determining subject matter eligibility, Examiner submits that the independent claim(s) 1, 16, and 17 recite(s) a system, a computer program (assuming product or medium), and a method for procurement management. Therefore, the claims as a whole are considered as being in a statutory category under Step 1 of the test.
Regarding Step 2A, prong 1, Examiner submits that the claims as a whole are directed to a judicially recognized exception that is an abstract idea. The claimed invention is drawn to an abstract idea of procurement management, by specifically including a processor configured to “access a supplier terminal of each supplier to update…a supply condition of the each supplier…”, “specify a plurality of suppliers that can supply an article…”, “cause the purchasable quantity to be displayed on a user terminal…”, “acquire the requestion condition…”, “automatically determine…whether or not a distribution condition…is satisfied…”, “automatically allocate the request quantity to one supplier…when determining that the distribution condition is not satisfied…”, “automatically select two or more suppliers…when determining that the distribution condition is satisfied, distribute the request quantity among the supplying supplier group…”; and “receive a request of a delivery time check…”, “wherein…the processor acquires from the supplier terminal a quantity of the article that can be supplied by the each supplier…calculates the purchasable quantity by adding the quantity of articles supplied by the each supplier…and compares the purchasable quantity with the request quantity”, and “where the processor causes a web page to be displayed on the user terminal…”. The limitations of at least “determine…whether or not a distribution condition…is satisfied…”, “allocate the request quantity to one supplier…when determining that the distribution condition is not satisfied…”, and “select two or more suppliers…when determining that the distribution condition is satisfied, distribute the request quantity among the supplying supplier group…”, as drafted are drawn to a process that, under its broadest reasonable interpretation, falls within the abstract idea grouping of Certain Methods of Organizing Human Activity (i.e. commercial or legal interactions including agreements in the form of contracts; legal obligations; advertising, marketing or sales activity or behaviors; business relations; or managing personal behavior or relationships or interactions between people including social activities, teaching, and following rules or instructions). That is, the claims are directed to the concept of procurement management. If a claim limitation/invention, under its broadest reasonable interpretation, can be construed as describing advertising, marketing or sales activity or behaviors, business relations, or the managing of personal behavior or relationships or interactions between people, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. In particular, the steps together are accomplishing procurement management, which is related to the managing of personal behavior or relationships or interactions between people, including at least social activities, teaching, and following rules or instructions. Additionally, the limitation of at least “wherein…the processor acquires from the supplier terminal a quantity of the article that can be supplied by the each supplier…calculates the purchasable quantity by adding the quantity of articles supplied by the each supplier…and compares the purchasable quantity with the request quantity” is drawn to performing calculations relating to calculating the purchasable quantity and comparing certain quantities, which is drawn to the abstract idea grouping of Mathematical Concepts (i.e. mathematical relationships, mathematical formulas or equations, mathematical calculations). Accordingly, the claims recite an abstract idea.
Regarding Step 2A, prong 2, Examiner submits that the claims do not recite additional elements that integrate the judicial exception into a practical application. Examiner submits that the claims at hand in fact do not include any recitation of additional elements in the claim beyond the judicial exception that would integrate the judicial exception into a practical application. To be considered statutory, the claims require an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. In this regard, Examiner submits that there are no such additional elements that improve the functioning of a computer to any other technology or technical field, apply or use a judicial exception to effect a particular treatment, apply the judicial exception with or by use of a particular machine, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Accordingly, the claims recite an abstract idea.
Regarding Step 2B drawn to determining if the claim recites additional elements amounting to significantly more than the judicial exception, Examiner submits that the claims in fact do not include any recitation of additional elements that would constitute anything significantly more. In particular, the claim only recites the additional elements of using a processor and displaying a web page to perform the steps of the invention. The processor and the web page in the claimed steps are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of computing or processing) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea and amount(s) to no more than: (i) mere instructions to implement the idea on a computer, and/or (ii) recitation of generic computer structure that serves to perform generic computer functions that are well-understood, routine, and conventional activities previously known to the pertinent industry. In view of the recent Berkheimer decision and the Step 2B analysis of the above rejection, Examiner is reiterating the fact that the procurement management as claimed is a well-understood, routine, conventional activity and can readily conclude that the element(s) is widely prevalent or in common use in the relevant industry. Said conclusion is made based upon a factual determination supported by the specification, which states that the claimed invention is merely implemented using a user terminal, that is any kind of device which can be programmed including e.g., any kind of computer like a server or personal computer (see page 12, [0019]). Furthermore, Examiner relies on the court decisions discussed in MPEP § 2106.05(d)(II) as noting the well-understood, routine, conventional nature of the additional element(s), such as receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) (“Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink.” (emphasis added)). In contrast to the Enfish decision where the claims focused on a specific improvement—a particular database technique—in how computers could carry out one of their basic functions of storage and retrieval of data, the present case is drawn to certain independently abstract ideas that use computers as tools. Enfish, 822 F.3d at 1335–36; see Bascom, 2016 WL 3514158, at *5; cf. Alice, 134 S. Ct. at 2360 (noting basic storage function of generic computer). Furthermore, the instant claims’ invocation of computers, and/or networks, and/or displays does not transform the claimed subject matter into patent-eligible applications. The claims at issue do not require any nonconventional computer, network, or display components, or even a “non-conventional and non-generic arrangement of known, conventional pieces,” but merely call for performance of the claimed information collection, analysis, and display functions “on a set of generic computer components” and display devices. Bascom, 2016 WL 3514158, at *6–7. Nothing in the claims, understood in light of the specification, requires anything other than off-the-shelf, conventional computer, network, and display technology for gathering, sending, and presenting the desired information. Such invocations of computers and networks that are not even arguably inventive are “insufficient to pass the test of an inventive concept in the application” of an abstract idea. buySAFE, 765 F.3d at 1353, 1355; see, e.g., Mortg. Grader, Inc. v. First Choice Loan Servs. Inc., 811 F.3d 1314, 1324–25 (Fed. Cir. 2016); Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370 (Fed. Cir. 2015); Internet Patents, 790 F.3d at 1348–49; Content Extraction, 776 F.3d at 1347–48. Therefore, these claim limitations, either individually or as an ordered combination, do not amount to significantly more than the abstract idea itself and do not transform the nature of the claim from the judicial exception into a patent-eligible application. The claims are not patent eligible.
Regarding claims 13-15 and 18, the dependent claims do not include any additional elements that constitute statutory matter. The dependent claims are directed to the same abstract idea as recited in the independent claims and have been found to either recite additional details that are part of the abstract idea itself (when analyzed under Step 2A Prong One), or include additional details that, when analyzed under Step 2A Prong Two and Step 2B, recite additional elements that fail to integrate the abstract idea into a practical application (Step 2A Prong Two) and fail to add significantly more to the abstract idea (Step 2B). Specifically, claims 13-15 describe further detail regarding displaying information related to split shipping, batch shipping, and purchasable quantity. The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claims) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to significantly more than the abstract idea itself. The dependent claims also recite steps that together with the independent claims are accomplishing the overall process of procurement management, which falls within the abstract idea grouping of Certain Methods of Organizing Human Activity (i.e. commercial or legal interactions including agreements in the form of contracts; legal obligations; advertising, marketing or sales activity or behaviors; business relations; or managing personal behavior or relationships or interactions between people including social activities, teaching, and following rules or instructions). Accordingly, the dependent claims are drawn to an abstract idea.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1 and 13-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (US 2002/0042755 A1, herein Kumar) in view of Ghaisas et al. (US 2002/0198756 A1, herein Ghaisas).
As per claim 1, Kumar teaches of a procurement management system comprising:
a processor, wherein
the processor (pg. 3, [0029], pg. 22, [0200-0202] and Fig. 6) is configured to:
access a supplier terminal of each supplier to update periodically or in real time a supply condition of the each supplier stored by a storage medium (pg. 1, [0011] which describes how the fulfillment system may managing the order promising and fulfillment in real-time to provide higher quality of service to the various entities in the supply chain; and pg. 2-3, [0025] which describes how the LFMs may provide component quotations to fulfillment server in substantially real-time, allowing for more rapid production of quotations for the client);
specify a plurality of suppliers that can supply an article to be requested by a user and a purchasable quantity of the article that can be supplied by the plurality of suppliers based on the updated supply condition of the each supplier, said purchasable quantity being a maximum quantity that can be purchased by the user;
cause the purchasable quantity to be displayed on a user terminal with an input screen for a request condition including a request quantity of the article that is requested by the user;
acquire the request condition including the request quantity of the article from the user terminal in response to input to the user terminal by the user (pg. 1, [0010] which describes the fulfilment system that includes a database operable to store at least one rule identifying a sourcing constraint associated with a customer; and pg. 3, [0026] which describes how clients submit ATP requests to the fulfilment server, including more line-items pertaining to specific products; and pg. 3, [0029] which describes how the clients may operate on one or more computers, including at least an input device; and pg. 3, [0030] which describes how the fulfillment server may maintain ATP server group and hierarchy information for sourcing purposes, including supplier groups, where the client or associated user may specify a preferred supplier or group, where the fulfillment server may also maintain a list of active suppliers associated with the group; and pg. 4, [0031-0032] which describes the modeling of multiple suppliers of the same product, where the fulfilment server may maintain for each product active suppliers for the product, including ranked or other list of suppliers for each product and required lot size or multiple for given product such that quotations are rounded based on this value; and pg. 4, [0033] which describes that the fulfillment server can process request line items through alternate groups or suppliers if a primary group or supplier is unable to service a request, where if an acceptable quotation response is not available from a preferred supplier, fulfillment server may locate product allocation or capacity availability from other potential suppliers; and pg. 5, [0037] which describes how a client may use contracts to create one or more guidelines or workflows to identify which suppliers will be used to procure a product and how to procure the product, including at least identifying a maximum number of suppliers to be used when sourcing a particular item for a client or a list of one or more specified suppliers to be use when sourcing a particular item; and pg. 5, [0042] which describes how a sourcing plan may be generated, including a selection of the suppliers to be used to supply one or more products, the quantity of products that each supplier will provide, and the method of transportation to be used by the suppliers, where the generation of the sourcing plan may be based on any suitable business rules and/or other parameters such as contracts, due dates, availability of items, client preferences, and/or logistics contracts; and pg. 8, [0058] which describes a RPA protocol where a customer requests one or more products and a supplier offers a promise that meets the requirements of the customer request as closely as possible; and pg. 9, [0064-0065] which describes how a user may select a product from a table of available products, etc. and once the user selects one or more products, the user may specify desired quantities, desired due dates, and any additional parameters);
automatically determine, when the request quantity, which is indicated by the request condition acquired from the user terminal, is less than the purchasable quantity, whether or not a distribution condition for distributing the request quantity of the article between two or more suppliers among the plurality of suppliers is satisfied based on the request condition and a latest supply condition which is stored by the storage medium and which is the supply condition including a supply quantity and a supply time of the article by each of the plurality of suppliers;
automatically allocate the request quantity to one supplier of the plurality of suppliers based on the latest supply condition, when determining that the distribution condition is not satisfied, and cause the supply time of the article by the one supplier to be displayed on the user terminal;
automatically select two or more suppliers from the plurality of suppliers as a supplying supplier group based on the latest supply condition, when determining that the distribution condition is satisfied, automatically distribute the request quantity among the supplying supplier group, and cause the supply time of the article by the supplying supplier group to be displayed on the user terminal (pg. 1, [0010] which describes receiving and communicating ATP requests corresponding to a desired product to at least one supplier associated with the desired product, where the supplier is determined according to at least one rule identifying the sourcing constraint; and pg. 2, [0022] which describes the example system, including sales force automation systems; and pg. 3, [0027] which describes how the client may generate a quotation confirmation to totally or partially accept the quotation, where ATP servers and/or LFMs generate component promises that consume supply and form binding commitments between the customer and suppliers as to the requested products; and pg. 3, [0030] which describes how the fulfillment server may maintain ATP server group and hierarchy information for sourcing purposes, including supplier groups, where the client may specify a preferred supplier or group; and pg. 4, [0031] which describes the modeling of multiple suppliers of the same product; and pg. 4, [0033-0034] which describes how the fulfillment server may process request line-items though alternate groups or suppliers if a primary group or supplier is unable to service a request, such that if an acceptable quotation response is not available from a preferred supplier, fulfilment server may location product allocation or materials or capacity availability from other potential suppliers, where the supplier information may be maintained in the fulfilment server; and pg. 5, [0038] which describes how a supplier may use certain heuristics to decide how that supplier may collaborate with other suppliers in filling an order; and pg. 5, [0039] which describes how the fulfillment server could use different business rules to process component quotations from ATP servers and/or LFMs based on the contents of the component quotations, such as whether the quotations involve the entire quantity of a desired product or only a portion of the requested quantity; and pg. 5, [0040] which describes how the fulfillment server could also use business rules to rank the responses from various suppliers, such as the ability of the supplier to meet a target price, and/or the ability of the supplier to meet a requested due date; and pg. 5, [0042] which describes how a sourcing plan may be generated, including a selection of the suppliers to be used to supply one or more products, the quantity of products that each supplier will provide, and the method of transportation to be used by the suppliers, where the generation of the sourcing plan may be based on any suitable business rules and/or other parameters such as contracts, due dates, availability of items, client preferences, and/or logistics contracts; and pg. 8, [0058] which describes the RPA in creating, managing, and fulfilling ATP requests, where the RPA protocol was developed for managing supply and demand requests between autonomous planning domains of a distributed supply chain, as well as how the fulfillment server may use business rules to examine a supplier quotation or promise and determine if it meets the requirements of the customer; and pg. 11, [0081] which describes how the fulfilment server examines the component quotations from suppliers and generates a unified quotation that provides the requested products to the client as close to the due date specified by the client as possible; and pg. 13, [0097] which describes how various LFMs may compute a variety of partial quotations or partial promises; and pg. 14, [0104] which describes how suppliers may respond to the component ATP requests with multiple acceptable ATP options, where multi-dimensional quotations are generated and sent to the client and presented to the client; and pg. 15, [0115-0117] and Fig. 3 which describes how the client sends a quotation confirmation to fulfilment server, the fulfilment server generates a single unified promise and sends it to the client for review and confirmation, and the client may selectively accept or reject one or more individual quotation line-items or the quotation as a whole); and
receiving a request of a delivery time check from the user terminal when the request quantity which is indicated by the request condition acquired from the user terminal exceeds the purchasable quantity (pg. 1, [0008] which describes how once delivery dates and other commitments have been made, it may be necessary to monitor the commitments throughout the production and logistics execution process to determine the effect of unexpected supply and demand changes; and pg. 4, [0032] which describes how fulfillment server may maintain sales channels and other hierarchical relationships between sales channels, which fulfillment server may use for order promising, including at least ranked or other list of suppliers for each product, a delivery window outside of which a late or early shipment is not acceptable; and pg. 5, [0037] which describes the use of contracts including heuristics for identifying which suppliers that should be used, identifying a maximum number of suppliers to be used when sourcing a particular item for a client, including a list of one or more specified suppliers to be used; and pg. 5, [0040] which describes how fulfillment server can use business rules to specify characteristics of potential supplier responses, including the ability of the supplier to meet a requested due date; and pg. 5, [0041] which describes how the fulfillment server could notify a user at a client that an ATP quotation meets or exceeds the business rules and allow the user to accept the quotation; and pg. 5, [0042] which describes the sourcing plan that includes a selection of the suppliers to be used to supply one or more products, the quantity of the products that each supplier will provide, where the generation of a sourcing plan may be based on any suitable business rules/parameters, including at least the due date requested by the client; and pg. 9, [0065] which describes how the initiation of the ATP request where the client or associated user may select one or more products and may further specify desired quantities, desired due dates, and any additional parameters; and pg.11, [0081] which describes the fulfillment server may generate unified quotations that provides the requested products to the client as close to the due date specified by the client as possible; and pg. 14, [0104-0105] which describes presenting the unified quotation to the client, where the fulfillment server attempts to provide a “best fit” response to the client).
However, Kumar fails to explicitly teach of acquiring from the supplier terminal a quantity of the article that can be supplied by the each supplier, calculating the purchasable quantity by adding the quantity of articles supplied by each supplier, comparing the purchasable quantity with the request quantity, and causing a web page to be displayed on a user terminal. Ghaisas teaches of resource capacity collaboration, specifically including:
wherein, when automatically determining the satisfaction of the distribution condition, the processor acquires from the supplier terminal a quantity of the article that can be supplied by the each supplier in the supplying supplier group, calculates the purchasable quantity by adding the quantity of the articles supplied by the each supplier in the supplying supplier group, and compares the purchasable quantity with the request quantity (pg. 1, [0004] which describes the invention including assessing a capacity value representing a capacity of the first resource to process one or more items, accessing a demand value representing a demand placed on the first resource, and automatically generating a notification if the demand value exceeds the capacity value, and reassigning at least a portion of the demand placed on the first resource in the first production period to at least one of a second resource and a second production period; and pg. 7; [0053] which describes how the server may perform functions automatically, including when a customer orders a quantity of product from a supplier, the server may automatically select which factories and resources will be used to product the product and how demand will be allocated across those factories and resources; and pg. 10, [0076-0078] which describes how the build plan entry allows a user to order a quantity of a product, which will be produced by a specific resource, where the supplier and/or factory may respond to the order by supplying a response that identifies the quantity of product that the supplier and/or factory is willing to produce for the customer, where if a customer orders a quantity through the build plan entry and the response of the supplier and/or factory is for less than the requested quantity, plan mismatch entry identifies the extend of the mismatch, and the view (400) may include one or more totals sections, which may identify the total quantity of products ordered by the user and the total quantity to which the supplier and/or factory has committed, where the total quantity of ordered products and the total quantity committed to may be broken down by resource and/or summed across all resources; and pg. 10, [0085-0086] which describes the view (600) of a capacity of a factory, including the capacity information section that identifies capacity information about resources in the selected factory, including a customer projected capacity, an actual capacity, and a capacity mismatch, and the view could include information about a group of factories or information about a single factory; and pg. 11, [0093-0095] which describes the method of resource capacity collaboration, including the server that stores the information as capacity information in the database, which may represent the total and/or available capacity of resources for processing one or more items as well as the demand information about the assignment of the resource to an item, such as storing information as demand information in the database, where the information is made available to the factory, supplier, and customer, and the server determines whether the demand placed on the resource exceeds the capacity of the resource and will generate a notification message including a warning message identifying the resource, the capacity of the resource, the demand currently placed on the resource, and the amount that the demand exceeds the capacity), and
wherein the processor causes a web page to be displayed on the user terminal, said web page containing a quantity input field through which the user can enter a quantity less than the purchasable quantity and a purchasable quantity field that shows the purchasable quantity that is stored in the storage medium (pg. 2, [0024-0025] which describes the collaboration system that includes a web subsystem that facilitates communication between the server and one or more browsers, where the web server delivers web pages to browsers of the customer, one or more suppliers, and/or one or more factories, where the web pages may contain information from the data and/or information generated by the server relating to resource capacity collaboration, such as the capacity of each resource nominally available to the customer, and a customer, associated supplier, and/or operator of an associated factory may reassign demand from a first resource to a second resource to produce the product for the customer; and pg. 3, [0026] which describes how the servlet engine stores and facilitates retrieval of one or more servlets, which may represent programs that receive input from users using browsers and generate displays for communication to the browsers; and pg. 10, [0076] which describes how the build plan entry allows a user to order a quantity of a product, which will be produced by a specific resource; and pg. 11, [0095-0096] which describes how the server communicates the warning message to a user associated with the customer and/or the supplier/factory, where the notification message may be communicated to the user by e-mail or by web page and the server reassigns at least a portion of the demand to other resources and/or other production periods without user input or by receiving instructions from one or more users associated with the customer, supplier, and/or factory instructing the server to move the demand to other resources or production periods).
Kumar teaches of collaborative fulfillment in a distributed supply chain environment. Ghaisas teaches of resource capacity collaboration, specifically including the calculating of the purchasable quantity, the comparing of the purchasable quantity with the request quantity, and the displaying of the web page as claimed. Both references are drawn to collaborative environments for managing orders. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Kumar with the above teachings of Ghaisas for the purpose of providing a customer with visibility into at least a portion of its supply chain, allowing the customer to identify which resources its suppliers and their factories use to produce a product and to collaborate with the suppliers and factory operators to help ensure that its demand is timely satisfied. By doing so, one would reasonably expect the overall appeal of the invention to improve in efficiency of demand fulfilment between customers and suppliers.
As per claim 16, it refers to a computer program for performing the above steps. It recites limitations already addressed by claim 1 above, and is therefore rejected under the same art and rationale. Furthermore, Kumar et al. (US 2002/0042755 A1, herein Kumar) discloses the steps are performed using computers and/or other suitable processing devices, including at least a processor and memory (pg. 3, [0029], pg. 22, [0200-0201] and Fig. 6).
As per claim 17, it refers to a control method for performing the above steps. It recites limitations already addressed by claim 1 above, and is therefore rejected under the same art and rationale. Furthermore, Kumar et al. (US 2002/0042755 A1, herein Kumar) discloses the steps are performed by the instant method as described for fulfillment in a distributed supply chain environment (abstract).
As per claim 13, Kumar in view of Ghaisas discloses all the elements of claim 1, and Kumar further teaches wherein the processor is configured to cause split shipping information to be displayed on the user terminal when determining that the distribution condition is satisfied, the split shipping information indicates that the request quantity of articles is separately shipped, and the split shipping information includes a quantity and the supply time of the article which are divided by each shipment (pg. 5, [0037] which describes how other heuristics can be used to identify a maximum number of suppliers to be used when sourcing a particular item for a client, a list of one or more specific suppliers to be used when sourcing a particular item for a client, a list of one or more logistics providers that can be selected by the client, or a supplier to ship an item, and pg. 5, [0038] which describes how a supplier may use certain heuristics to decide how they may collaborate with other suppliers in fulfilling an order; and pg. 6, [0048] which describes how the fulfillment center may be used when an order may not be fulfilled by a supplier and the fulfilment center generates and communicates an exception to the client, and may also attempt to identify one or more alternate shippers to supply the product to the client, using business rules or user preferences to identify contracts between the client and alternate shippers; and pg. 10, [0071] which describes request line-item attributes including the default ship-to address for the request line-item, a product UOM or primary unit of measure for the requested product, and a request quantity or quantity range of the product requested; and pg. 16, [0123] which describes the fulfilment center which is capable of processing client responses including full or partial acceptances, as well as how the LFMs may be statements of supplier shipment schedules and the fulfilment center may provide the ability to derive customer delivery dates for the multi-item order; and pg. 17, [0136] which describes the logistics functions that can coordinate multiple deliveries originating from multiple points to a destination, where the fulfilment center can identify calendars identifying outgoing shipments, incoming receipts, and in-transit shipments, and can further use business rules to select appropriate delivery services and carriers to use for a client, where the business rules may consider the shipping preferences of a client and a supplier, the delivery date at the client, the ship date from the supplier, and the costs of delivery to select one or more carriers and one or more delivery services).
As per claim 14, Kumar in view of Ghaisas discloses all the elements of claim 1, and Kumar further teaches wherein the processor is configured to cause batch shipping information to be displayed on the user terminal when determining that the distribution condition is satisfied, the batch shipping information indicates that the request quantity of articles is to be collectively shipped, and the batch shipping information includes the supply time for collectively shipping the request quantity of articles (pg. 5, [0037] which describes how other heuristics can be used to identify a maximum number of suppliers to be used when sourcing a particular item for a client, a list of one or more specific suppliers to be used when sourcing a particular item for a client, a list of one or more logistics providers that can be selected by the client, or a supplier to ship an item, and pg. 5, [0038] which describes how a supplier may use certain heuristics to decide how they may collaborate with other suppliers in fulfilling an order; and pg. 6, [0048] which describes how the fulfillment center may be used when an order may not be fulfilled by a supplier and the fulfilment center generates and communicates an exception to the client, and may also attempt to identify one or more alternate shippers to supply the product to the client, using business rules or user preferences to identify contracts between the client and alternate shippers; and pg. 10, [0071] which describes request line-item attributes including the default ship-to address for the request line-item, a product UOM or primary unit of measure for the requested product, a request quantity or quantity range of the product requested, and a line-item grouping that relates to multiple request line-items as logical grouping for delivery coordination, including bundled package of products or set items that must ship together; and pg. 16, [0123] which describes the fulfilment center which is capable of processing client responses including full or partial acceptances, as well as how the LFMs may be statements of supplier shipment schedules and the fulfilment center may provide the ability to derive customer delivery dates for the multi-item order; and pg. 17, [0136] which describes the logistics functions that can coordinate multiple deliveries originating from multiple points to a destination, where the fulfilment center can identify calendars identifying outgoing shipments, incoming receipts, and in-transit shipments, and can further use business rules to select appropriate delivery services and carriers to use for a client, where the business rules may consider the shipping preferences of a client and a supplier, the delivery date at the client, the ship date from the supplier, and the costs of delivery to select one or more carriers and one or more delivery services).
As per claim 15, Kumar in view of Ghaisas discloses all the elements of claim 1, and Kumar further teaches wherein the purchasable quantity is a capable quantity to be supplied by the plurality of suppliers (pg. 5, [0039] which describes how the fulfillment server could use different business rules to process component quotations from ATP servers and/or LFMs based on the contents of the component quotations, such as whether the quotations involve the entire quantity of a desired product or only a portion of the requested quantity; and pg. 5, [0042] which describes how a sourcing plan may be generated, including a selection of the suppliers to be used to supply one or more products, the quantity of products that each supplier will provide, and the method of transportation to be used by the suppliers, where the generation of the sourcing plan may be based on any suitable business rules and/or other parameters such as contracts, due dates, availability of items, client preferences, and/or logistics contracts; and pg. 10, [0071] which describes request line-item attributes including the default ship-to address for the request line-item, a product UOM or primary unit of measure for the requested product, a request quantity or quantity range of the product requested, and a line-item grouping that relates to multiple request line-items as logical grouping for delivery coordination, including bundled package of products or set items that must ship together).
As per claim 18, Kumar in view of Ghaisas discloses all the elements of claim 1, and Kumar further teaches the purchasable quantity field shows a quantity of articles that can be shipped on an order day (pg. 11, [0079] and pg. 12, [0083] which describes how the fulfillment server generates the component ATP requests with embedded business constraints, where the component request may also support information such as request quantity, request date, category/attributes, ship complete, ship on-time, etc.; and pg. 12, [0086-0088] which describes how the LFM is involved in quotation, promise, acceptance, shipping, and archive operations for the associated ATP server, where if the ship complete attribute within the component ATP request requires the request to be met in full, and the availability in the ATP server was less than the requested quantity attribute, then the LFM might indicate the component quotation as having failed and provide an appropriate descriptive failure annotation; and pg. 14, [0105] which describes how if the ship on-time attribute for the ATP request specifies that the shipment must be received on time, and one or more component quotations are in some way insufficient, fulfillment server may assign a failure status to the ATP request in its entirety).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ASHLEY Y YOUNG whose telephone number is (571)270-5294. The examiner can normally be reached Mondays, Tuesdays, and Thursdays, 9:00a-3:00p, EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Beth Boswell can be reached at (571) 272-6737. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Servic