DETAILED ACTION
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 .
Status of Application
This office action is in response to the most recent filings filed by applicant on 10/29/2024.
No claims are amended
No claims are cancelled
No claims are added
Claims 1-19 are pending
Claim Rejections - 35 USC § 112
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims 1-9 in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are in claim 1: “wherein the business backend is configured to:”, “wherein the interface service is configured to:”, “wherein the message middleware is configured to:”; “wherein the interface service is configured to”.
The originally submitted specification shows in [0036] The present disclosure provides, inter alia, a computer-implemented method, an apparatus for managing production of one or more products, and a computer-program product that substantially obviate one or more of the problems due to limitations and disadvantages of the related art. In one aspect, the present disclosure provides An apparatus for managing production of one or more products. In some embodiments, the apparatus for managing production of one or more products includes a business backend; an interface service; a persistent data storage; a processor; and a message middleware. Optionally, the business backend is configured to extract and organize data; and dispatch business data to the interface service. Optionally, the interface service is configured to perform data validation on the business data received from the business backend; and transmit the business data to the persistent data storage and the message middleware. Optionally, the persistent data storage is configured to store the business data received from the interface service as a reference for the calculation and analysis; and transmit data to the processor. Optionally, the processor is configured to calculate overstock quantity and determine overstock type. Optionally, the message middleware is configured to receive the business data from the interface service, and receive analysis results from the processor; and transmit the analysis results to interface service. Optionally, the interface service is configured to monitor message queue in the message middleware for updates regarding ongoing processes.
Claim 19 also recites: “A computer-program product, comprising a non-transitory tangible computer-readable medium having computer-readable instructions thereon, the computer-readable instructions being executable by a processor to cause the processor to perform: extracting and organizing data by a business backend; dispatching, by the business backend, business data to an interface service; performing, by an interface service, data validation on the business data received from the business backend; transmitting, by the interface service, the business data to a persistent data storage and a message middleware; storing, by the persistent data storage, the business data received from the interface service as a reference for the calculation and analysis; transmitting, by the persistent data storage, data to the processor; calculating overstock quantity and determining overstock type, by the processor; receiving, by the message middleware, the business data from the interface service, and receive analysis results from the processor; transmitting, by the message middleware, the analysis results to interface service; and monitoring, by the interface service, message queue in the message middleware for updates regarding ongoing processes.”
Both the specification and claim 19 show how the limitations: “wherein the business backend is configured to:”, “wherein the interface service is configured to:”, “wherein the message middleware is configured to:”; “wherein the interface service is configured to” are located on the processor.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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-19 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Step One - First, pursuant to step 1 in the January 2019 Guidance on 84 Fed. Reg. 53, the claims 10-18 is/are directed to a method which is a statutory category.
Step One - First, pursuant to step 1 in the January 2019 Guidance on 84 Fed. Reg. 53, the claims 1-9 is/are directed to an apparatus which is a statutory category.
Step One - First, pursuant to step 1 in the January 2019 Guidance on 84 Fed. Reg. 53, the claims 19 is/are directed to a computer program product which is a statutory category.
Step 2A Prong 1: Identify the Abstract Idea(s)
The Alice framework, steps 2A-Prong One (part 1 of Mayo Test), here, the claims are analyzed to determine if the claims are directed to a judicial exception. MPEP 2106.04(a). In determining, whether the claims are directed to a judicial exception, the claims are analyzed to evaluate whether the claims recite a judicial exception (Prong One of Step 2A), and whether the claims recite additional elements that integrate the judicial exception into a practical application (Prong Two of Step 2A). See 2019 Revised Patent Subject Matter Eligibility Guidance (“PEG” 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50-57 (Jan. 7, 2019)).
Under the 2019 PEG, Step 2A under which a claim is not “directed to” a judicial exception unless the claim satisfies a two-prong inquiry. Further, particular groupings of abstract ideas are consistent with judicial precedent and are based on an extraction and synthesis of the key concepts identified by the courts as being abstract.
Independent claims 1, 10 and 19, with respect to the Step 2A, Prong One, when “taken as a whole” the claims as drafted, and given their broadest reasonable interpretation, fall within the Abstract idea grouping of “certain methods of organizing human activity” (business relations; relationships or interactions between people). For instance, independent Method Claim 10 is directed to an abstract idea, as evidenced by claim limitations “extract and organize data; and dispatch business data; perform data validation on the business data received; and transmit the business data; store the business data as a reference for the calculation and analysis; and transmit data to the processor; wherein the processor is configured to calculate overstock quantity and determine overstock type; receive the business data from the interface service, and receive analysis results from the processor; and transmit the analysis results; wherein monitor message queue in the message middleware for updates regarding ongoing processes, calculating overstock quantity and determining overstock type.”
The specification shows in [0003] Management of production of products is a complicated process, particularly when the process involves a large number of products and starting materials. In manufacturing a product, the management becomes more difficult when the demand for products and engineering for manufacturing processes can quickly change over a short period of time. Traditional manual management or simple programming are insufficient to manage production, often resulting in material overstock and waste.
In light of the specification, these claim limitations belong to the grouping of “certain methods of organizing human activity” because the claims are related to managing production of products for one or more human entities involves organizing human activity based on the description of “certain methods of organizing human activity” provided by the courts. The court have used the phrase “Certain methods of organizing human activity” as —fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
Independent Claims 1 and 19 is/are recite substantially similar limitations to independent claim 10 and is/are rejected under 2A for similar reasons to claim 10 above.
Step 2A Prong 2: Additional Elements That Integrate the Judicial Exception into a Practical Application
With respect to the Step 2A, Prong Two - This judicial exception is not integrated into a practical application. In particular, the claim recites additional elements: “An apparatus for managing production of one or more products, comprising: A computer-implemented method, comprising: A computer-program product, comprising a non-transitory tangible computer-readable medium having computer-readable instructions thereon, the computer-readable instructions being executable by a processor to cause the processor to perform: a business backend; an interface service; a persistent data storage; a processor; and a message middleware; wherein the business backend is configured to: to the interface service; wherein the interface service is configured to: from the business backend; to the persistent data storage and the message middleware; wherein the persistent data storage is configured to: received from the interface service; wherein the message middleware is configured to: to interface service, the interface service is configured to, by the processor” at a high level of generality such that it amounts to no more than: adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea with no significantly more elements.
The limitations discussed above are shown in specification: [0137]-[0138]. In light of the additional elements do not integrate the abstract idea into practical application because they do not impose any meaningful limitations on practicing the abstract idea. As a result, claims 1, 10 and 19 do not provide any specifics regarding the integration into a practical application when recited in a claim with a judicial exception. See MPEP 2106.05(f).
Similarly dependent claims 2-9 and 11-18 are also directed to an abstract idea under 2A, first and second prong. In the present application, all of the dependent claims have been evaluated and it was found that they all inherit the deficiencies set forth with respect to the independent claims. For instance, dependent claim 11 recite “further comprising: receiving, including information on one or more of production requirements, material inventory, bill of materials data, substitute material, and material priority” and dependent claim 14 recite “further comprising: determining, by the processor, which inventory items should be prioritized for processing, redistribution, or optimization; applying, by the processor, a set of rules to decide the next steps for processing the data; and using, by the processor, a linear programming model to optimize decisions about inventory levels and resource allocation to achieve cost-effectiveness or efficiency.” Here, these claims offer further descriptive limitations of elements found in the independent claims which are similar to the abstract idea noted in the independent claim above.
Dependent claims 12 recites “further comprising parsing tag field, by the processor, during which tags or identifiers in the data received from the persistent data storage is analyzed.”. Dependent claims 13 recites “further comprising matching processing method, by the processor, during which an algorithm is selected.” Dependent claims 17 recites “further comprising: pushing, and receiving, calculation requests and display results of overstocked inventory management.”. Dependent claims 18 recites “further comprising performing, by a container engine, one or more of container construction, container orchestration, and application management”. In the claim limitations, “comprising parsing tag field, by the processor; data storage; comprising matching processing method, by the processor, during which an algorithm is selected; by the interface service, results to the user interface terminal for display; by a user interface terminal, by a container engine, one or more of container construction, container orchestration, and application management” is an additional element, but it is still being recited such that it amounts to no more than: adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f). As a result, Examiner asserts that dependent claims, such as dependent claims 2-9 and 11-18 are also directed to the abstract idea identified above.
Step 2B: Determine Whether Any Element, Or Combination, Amount to “Significantly More” Than the Abstract Idea Itself
With respect to Step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. First, the invention lacks improvements to another technology or technical field [see Alice at 2351; 2019 IEG at 55], and lacks meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment [Alice at 2360, 2019 IEG at 55], and fails to effect a transformation or reduction of a particular article to a different state or thing [2019 IEG, 55]. For the reasons articulated above, the claims recite an abstract idea that is limited to a particular field of endeavor (MPEP § 2106.05(h)) and recites insignificant extra-solution activity (MPEP § 2106.05(g)). By the factors and rationale provided above with respect to these MPEP sections, the additional elements of the claims that fail to integrate the abstract idea into a practical application also fail to amount to “significantly more” than the abstract idea.
As discussed above with respect to integration of the abstract idea into a practical application, the additional element(s) of “An apparatus for managing production of one or more products, comprising: A computer-implemented method, comprising: A computer-program product, comprising a non-transitory tangible computer-readable medium having computer-readable instructions thereon, the computer-readable instructions being executable by a processor to cause the processor to perform: a business backend; an interface service; a persistent data storage; a processor; and a message middleware; wherein the business backend is configured to: to the interface service; wherein the interface service is configured to: from the business backend; to the persistent data storage and the message middleware; wherein the persistent data storage is configured to: received from the interface service; wherein the message middleware is configured to: to interface service, the interface service is configured to, by the processor” are insufficient to amount to significantly more. Applicants originally submitted specification describes the computer components above at least in page/ paragraph [0137]-[0138]. In light of the specification, it should be noted that the components discussed above did not meaningfully limit the abstract idea because they merely linked the use of the abstract idea to a particular technological environment (i.e., "implementation via computers"). In light of the specification, it should be noted that the claim limitations discussed above are merely instructions to implement the abstract idea on a computer. See MPEP 2106.05(f). (See MPEP 2106.05(f) - Mere Instructions to Apply an Exception - “Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct. at 235). Mere instructions to apply an exception using computer component cannot provide an inventive concept.). The additional elements amount to no more than a recitation of generic computer elements utilized to perform generic computer functions, such as performing repetitive calculations, Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); and storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; see MPEP 2106.05(d)(II).
Therefore, the claims at issue do not require any nonconventional computer, network, or display components, or even a “non-conventional and non-generic arrangement of know, conventional pieces,” but merely call for performance of the claimed on a set of generic computer components” and display devices. All of these additional elements are significantly more because these, again, are merely the software and/or hardware components used to implement the abstract idea on a general-purpose computer. Generically recited computer elements do not add a meaningful limitation to the abstract idea because the Alice decision noted that generic structures that merely apply abstract ideas are not significantly more than the abstract ideas.
The computing elements with a computing device is recited at high level of generality (e.g. a generic device performing a generic computer function of processing data). Thus, this step is no more than mere instructions to apply the exception on a generic computer. In addition, using a processor to process data has been well- understood routing, conventional activity in the industry for many years. Generic computer features, such as system or storage, do not amount to significantly more than the abstract idea. These limitations merely describe implementation for the invention using elements of a general-purpose system, which is not sufficient to amount to significantly more. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976; Versata Dev. Group, Inc. v. SAP Am. Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1791 (Federal Circuit 2015).
The claim fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
Independent Claims 1 and 19 is/are recite substantially similar limitations to independent claim 10 and is/are rejected under 2B for similar reasons to claim 10 above.
Further, it should be noted that additional elements of the claimed invention such as claim limitations when considered individually or as an ordered combination along with the other limitations discussed above in method claim 10 also do not meaningfully limit the abstract idea because they merely linked the use of the abstract idea to a particular technological environment (i.e., "implementation via computers"). In light of the specification, it should be noted that the claim limitations discussed above are merely instructions to implement the abstract idea on a computer. See MPEP 2106.
Similarly, dependent claims 2-9 and 11-18 also do not include limitations amounting to significantly more than the abstract idea under the second prong or 2B of the Alice framework. In the present application, all of the dependent claims have been evaluated and it was found that they all inherit the deficiencies set forth with respect to the independent claims. Further, it should be noted that the dependent claims do not include limitations that overcome the stated assertions. Here, the dependent claims recite features/limitations that include computer components identified above in part 2B of analysis of independent claims 1, 10 and 19. As a result, Examiner asserts that dependent claims, such as dependent claims 2-9 and 11-18 are also directed to the abstract idea identified above.
Further, Examiner notes that the addition limitations, when considered as an ordered combination, add nothing that is not already present when looking at the additional elements individually.
For more information on 101 rejections, see MPEP 2106, January 2019 Guidance at https://www.govinfo.gov/content/pkg/FR-2019-01 -07/pdf/2018-28282.pdf
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over (US 2022/0188756 A1) Morris, further in view of (US 2022/0083954 A1) Starostenko and (US 2017/0185943 A1) Wang et al.
As per claims 1, 10 and 19: Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
An apparatus for managing production of one or more products, comprising (Reference Morris: Abstract: The present systems and methods generally relate to optimizing inventory levels using machine learning methodologies. Using novel techniques, the present systems and methods can process and analyze inventory data to determine inventory items that are stocked out or overstocked and provide recommendations for mitigating these events, such that users can optimize their inventory levels with minimal manual intervention. For example, in various embodiments, the present systems and methods ingest inventory data, normalize and extract relevant portions of the inventory data, and sort the inventory data into one or more categories based on the root cause of any identified stockout or overstock events.):
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
A computer-implemented method, comprising (Reference Morris: [0008] In particular embodiments, the present disclosure describes the method herein, further including: receiving an operational dataset of inventory data, wherein the operational dataset includes a plurality of items stocked or to be stocked with a particular entity; and applying the machine learning model to the operational dataset of inventory data to associate each of the plurality of items in the operational dataset with a respective category of the plurality of categories of stock events. In one or more embodiments, aspects of the present disclosure describes the method herein, wherein the plurality of categories of stock events include: stockouts, overstocks or appropriately stocked. In some embodiments, the present disclosure describes the method herein, wherein one or more respective categories of the plurality of categories of stock events are associated with one or more reasons for the stock events. Generally, in certain embodiments, the present disclosure describes the method herein, wherein the efficacy is a measure of deviation between the pre-associated category of stock events to the estimated category of stock events, and an acceptable efficacy includes a margin of error below a predefined threshold for the deviation. In various embodiments, the present disclosure describes the method herein, wherein the particular entity includes a particular physical location, facility, company, or organization. In at least one embodiment, the present disclosure describes the method herein, wherein the plurality of categories include one of a first plurality of category subsets selected from the group including: stockouts; overstocks; and appropriately stocked. In particular embodiments, aspects of the present disclosure describe the method herein, wherein the first plurality of category subsets further include one of a second plurality of category subsets selected from the group including: replenishment orders for new items to be stocked with the particular entity made too late; one or more large unexpected customer sales depleted items stocked with the particular entity; undetected increases in demand of established items stocked with the particular entity; items stocked or to be stocked with the particular entity are low volume and difficult to forecast sales; purchase orders for items stocked or to be stocked are insufficient for strong seasonal pattern; purchase orders for items stocked or to be stocked are insufficient for promotions; late or short shipment of items to be stocked at particular location; new items stocked are selling more than forecasted; one or more items stocked were purchased in excess of forecast due to vendor minimums; one or more items stocked were purchased in excess of forecast due to vendor promotions; undetected decreases in demand of established items stocked with a particular entity; purchase orders for items stocked or to be stocked are packaged in quantities in excess of forecast; purchase orders for items stocked or to be stocked are overly ambitious for promotions; early or surplus shipment from vendor of items to be stocked at particular location; and new items stocked are selling less than expected.):
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
A computer-program product, comprising a non-transitory tangible computer-readable medium having computer-readable instructions thereon, the computer-readable instructions being executable by a processor to cause the processor to perform (Reference Morris: [0009] According to various embodiments, the present disclosure generally describes a system for managing product inventory levels including: a database that stores inventory data; and a non-transitory computer readable medium that controls a processor that performs the steps of: defining a plurality of categories of stock events; receiving a training dataset of inventory data, wherein the training dataset includes a plurality of items stocked or to be stocked with a particular entity; associating each of the plurality of items in the training dataset with a respective category of the plurality of categories of stock events; generating and training a machine learning model based on the training dataset of inventory data; receiving an evaluation dataset of inventory data, wherein the evaluation dataset includes a pre-associated category of stock events for each of the plurality of items; applying the machine learning model to the evaluation dataset of inventory data to generate an estimated category of stock events for each of the plurality of items; and comparing, for each of the plurality of items, the pre-associated category of stock events to the estimated category of stock events to determine an efficacy of the machine learning model.)
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
a business backend;
The claim limitation above is broad, it is unclear if the backend is software or hardware. The specification describes the above limitation as [0036]: Optionally, the business backend is configured to extract and organize data. Also, see [0100].
Even though Reference Morris shows in [0064]: the system performs feature extraction on the normalized inventory data to convert the data into a set of inputs (e.g., features) suitable for training the machine learning model. [0057] As shown in FIG. 3, the exemplary process begins with step 302, in which the system is configured to define categories of inventory events. In particular embodiments, the categories defined pertain to the type of inventory event (e.g., stockout or overstock). In these embodiments (and others), the type of inventory event is further categorized into one or more reasons for a stockout or overstock as discussed above in relation to FIG. 2. In certain embodiments, the categories may be defined manually by a user of the system via a user interface that allows the user to interact with the system. In various embodiments, the system may automatically define the categories of inventory events based on inventory data as may be received and processed by the system. Here, it is reasonably understood that the system of Reference Morris has communications happening in the backend, which reads on the claim limitations above.
Reference Morris does not explicitly show “backend” in the claim above. However, Reference Starostenko shows the above limitation at least in [0037] In various embodiments, and as described further herein, the e-commerce platform 100 may be implemented through a processing facility including a processor and a memory, the processing facility storing a set of instructions that, when executed, cause the e-commerce platform 100 to perform the e-commerce and support functions as described herein. The processing facility may be part of a server, client, network infrastructure, mobile computing platform, cloud computing platform, stationary computing platform, or other computing platform, and provide electronic connectivity and communications between and amongst the electronic components of the e-commerce platform 100, retailer devices 102, payment gateways 106, application development 108, channels 110, shipping providers 112, customer devices 150, POS devices 152, supplier devices 160, and the like. The e-commerce platform 100 may be implemented as a cloud computing service, a software as a service (SaaS), infrastructure as a service (IaaS), platform as a service (PaaS), desktop as a Service (DaaS), managed software as a service (MSaaS), mobile backend as a service (MBaaS), information technology management as a service (ITMaaS), and the like, such as in a software and delivery model in which software is licensed on a subscription basis and centrally hosted (e.g., accessed by users using a thin client via a web browser, accessed through by POS devices 152, and the like). In various embodiments, elements of the e-commerce platform 100 may be implemented to operate on various platforms and operating systems, such as iOS, Android, over the internet, and the like.
Reference Morris and Reference Starostenko are analogous prior art to the claimed invention because the references generally relate to field of inventory management. Further, said references are part of the same classification, i.e., G06Q10. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Starostenko, particularly the business backened (Starostenko: shown in [0037]), in the disclosure of Reference Morris, particularly in the system performs feature extraction on the normalized inventory data to convert the data into a set of inputs (e.g., features) suitable for training the machine learning model (Morris: shown in [0064]), in order to provide for a system that may support a great number of independently administered storefronts 139 and process a large volume of transactional data on a daily basis for a variety of products. Transactional data may include customer contact information, billing information, shipping information, information on products purchased, information on services rendered, and any other information associated with business through the e-commerce platform 100. In various embodiments, the e-commerce platform 100 may store this data in a data facility 134. The transactional data may be processed to produce analytics 132, which in turn may be provided to retailers or third-party commerce entities, such as providing consumer trends, marketing and sales insights, recommendations for improving sales, evaluation of customer behaviors, marketing and sales modeling, trends in fraud, and the like, related to online commerce, and provided through dashboard interfaces, through reports, and the like. The e-commerce platform 100 may store information about business and retailer transactions, and the data facility 134 may have many ways of enhancing, contributing, refining, and extracting data, where over time the collected data may enable improvements to aspects of the e-commerce platform 100 as taught by Reference Starostenko (see at least in [0045]), where upon the execution of the method and system of Reference Starostenko for reallocation of inventory from a supplier to a retailer (see at least in Abstract) so that the process of inventory management can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar inventory management field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Morris in view of Reference Starostenko, the results of the combination were predictable (MPEP 2143 A).
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
an interface service (Reference Morris shows in [0057] As shown in FIG. 3, the exemplary process begins with step 302, in which the system is configured to define categories of inventory events. In particular embodiments, the categories defined pertain to the type of inventory event (e.g., stockout or overstock). In these embodiments (and others), the type of inventory event is further categorized into one or more reasons for a stockout or overstock as discussed above in relation to FIG. 2. In certain embodiments, the categories may be defined manually by a user of the system via a user interface that allows the user to interact with the system. In various embodiments, the system may automatically define the categories of inventory events based on inventory data as may be received and processed by the system. [0058] At step 304, the system receives inventory data. In various embodiments, the inventory data may be manually entered into the system by a user (e.g., system administrator) via the user interface. In particular embodiments, the system may receive the inventory data from a third-party inventory management tool (e.g., an ERP tool). In these embodiments (and others), the system is configured to interface with various third-party applications via API integrations and/or various file sharing techniques (e.g., FTP transfers, cloud sharing, etc.). In one or more embodiments, if the inventory data is received from a third-party system, the data may be parsed and normalized prior to processing. In certain embodiments, the inventory data received by the system may be inventory data that was processed and output by the system and subsequently fed back into the system for additional processing. In at least one embodiment, the inventory data received by the system includes, but is not limited to: inventory type, product name, product description, quantity, location, days on hand, price, cost, number of units sold, last stockout event, last overstock event, lead time for replenishment, historical inventory data, and any other suitable information relevant to the systems and methods described herein. In one embodiment, the inventory data may be for a single user (e.g., a distributor). In another embodiment, the inventory data may be for a group of multiple users (e.g., several distributors). In certain embodiments, inventory data may be aggregated to assess various stockout and overstock trends and statistics (e.g., industry trends, geographic trends, etc.);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
a persistent data storage (Reference Morris: [0086] From the foregoing, it will be understood that various aspects of the processes described herein are software processes that execute on computer systems that form parts of the system. Accordingly, it will be understood that various embodiments of the system described herein are generally implemented as specially-configured computers including various computer hardware components and, in many cases, significant additional features as compared to conventional or known computers, processes, or the like, as discussed in greater detail herein. Embodiments within the scope of the present disclosure also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media which can be accessed by a computer, or downloadable through communication networks. By way of example, and not limitation, such computer-readable media can include various forms of data storage devices or media such as RAM, ROM, flash memory, EEPROM, CD-ROM, DVD, or other optical disk storage, magnetic disk storage, solid state drives (SSDs) or other data storage devices, any type of removable non-volatile memories such as secure digital (SD), flash memory, memory stick, etc., or any other medium which can be used to carry or store computer program code in the form of computer-executable instructions or data structures and which can be accessed by a general purpose computer, special purpose computer, specially-configured computer, mobile device, etc.);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
a processor (Reference Morris: [0014] the present disclosure generally describe the system herein, further configured for: associating each of the plurality of items in the operational dataset with the respective category of the plurality of categories of stock events; and training the machine learning model based on the operational dataset of inventory data. In at least one embodiment, the present disclosure generally describe the system herein, wherein the efficacy is a measure of deviation between the pre-associated category of stock events to the estimated category of stock events, and an acceptable efficacy includes a margin of error below a predefined threshold for the deviation. In certain embodiments, the present disclosure generally describe the system herein, wherein the stock events are selected from the group including: stockouts, overstocks and appropriately stocked. In at least one embodiment, the present disclosure generally describe the system herein, wherein one or more respective categories of the plurality of categories are associated with one or more reasons for stock events. In certain embodiments, aspects of the present disclosure generally describe the system herein, wherein the plurality of categories include one of a first plurality of category subsets selected from the group including: stockouts; overstocks; and appropriately stocked. In particular embodiments, the present disclosure generally describe the system herein, wherein the first plurality of category subsets further include one of a second plurality of category subsets including the one or more reasons for stock events. In several embodiments, the present disclosure generally describe the system herein, wherein the one or more reasons for stock events are selected from the group including: replenishment orders for new items to be stocked with the particular entity made too late; one or more large unexpected customer sales depleted items stocked with the particular entity; undetected increases in demand of established items stocked with the particular entity; items stocked or to be stocked with the particular entity are low volume and difficult to forecast sales; purchase orders for items stocked or to be stocked are insufficient for strong seasonal pattern; purchase orders for items stocked or to be stocked are insufficient for promotions; late or short shipment of items to be stocked at particular location; new items stocked are selling more than forecasted; one or more items stocked were purchased in excess of forecast due to vendor minimums; one or more items stocked were purchased in excess of forecast due to vendor promotions; undetected decreases in demand of established items stocked with a particular entity; purchase orders for items stocked or to be stocked are packaged in quantities in excess of forecast; purchase orders for items stocked or to be stocked are overly ambitious for promotions; early or surplus shipment from vendor of items to be stocked at particular location; and new items stocked are selling less than expected. In some embodiments, aspects of the present disclosure generally describe the system herein, wherein the processor is further configured for: retrieving the stock event reason for each of the plurality of items in the operational dataset; and generating a recommendation for resolving the stock event reason. In various embodiments, the present disclosure generally describes the system herein, wherein the processor is further configured for: integrating with a third-party ordering system and initiating an inventory order based on the recommendation generated. In at least one embodiment, the present disclosure generally describe the system herein, wherein the output includes a printable report or a display on a graphical user interface of a computing device.); and
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
a message middleware
Reference Morris shows the ability to send messages or notifications: in [0045] In particular embodiments, the inventory system 100 may be configured to communicate with a vendor to adjust purchase orders based on the classification of identified stockouts or overstocks. Continuing with the above example, upon determining that the color-safe bleach was stocked out because replenishment purchase orders were made too late, the inventory system 100 initiates a communication with the vendor of the color-safe bleach to place an immediate order for the bleach and to adjust the timing of future purchase orders to eliminate the likelihood of a future stockout event for this item. In some embodiments, the inventory system 100 may communicate with the vendor 106 via email or direct messaging. In one or more embodiments, the inventory system 100 may integrate with the vendor's 106 inventory system to automatically place an order or to schedule/adjust future orders. In certain embodiments, the inventory system 100 is configured to issue a notification to the retail establishment 104 such that the retail establishment 104 can communicate with the vendor 106 to place an order or schedule/adjust future orders. Reference Morris does not explicitly show “middleware”, it is reasonably understood that the system that sends the message in Morris on [0045] has middleware that performs the task.
Reference Wang shows the above limitations in [0090] Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
Reference Morris, Reference Starostenko and Reference Wang are analogous prior art to the claimed invention because the references generally relate to field of inventory management. Further, said references are part of the same classification, i.e., G06Q10. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Wang, particularly the message middleware (Wang: shown in [0090]), in the disclosure of Reference Morris and Reference Starostenko, particularly in the ability to send messages or notifications (shown in [0045]), in order to provide for a system that system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet as taught by Reference Wang (see at least in [0090]), where upon the execution of the method and system of Reference Morris and Reference Starostenko for optimizing inventory levels using machine learning methodologies (Morris: see at least in Abstract) so that the process of inventory management can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar inventory management field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Morris and Reference Starostenko in view of Reference Wang, the results of the combination were predictable (MPEP 2143 A);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
wherein the business backend is configured to: extract and organize data; and a business backend;
The claim limitation above is broad, it is unclear if the backend is software or hardware. The specification describes the above limitation as [0036]: Optionally, the business backend is configured to extract and organize data. Also, see [0100].
Even though Reference Morris shows in [0064]: the system performs feature extraction on the normalized inventory data to convert the data into a set of inputs (e.g., features) suitable for training the machine learning model. [0057] As shown in FIG. 3, the exemplary process begins with step 302, in which the system is configured to define categories of inventory events. In particular embodiments, the categories defined pertain to the type of inventory event (e.g., stockout or overstock). In these embodiments (and others), the type of inventory event is further categorized into one or more reasons for a stockout or overstock as discussed above in relation to FIG. 2. In certain embodiments, the categories may be defined manually by a user of the system via a user interface that allows the user to interact with the system. In various embodiments, the system may automatically define the categories of inventory events based on inventory data as may be received and processed by the system. Here, it is reasonably understood that the system of Reference Morris has communications happening in the backend, which reads on the claim limitations above.
Reference Morris does not explicitly show “backend” in the claim above. However, Reference Starostenko shows the above limitation at least in [0037] In various embodiments, and as described further herein, the e-commerce platform 100 may be implemented through a processing facility including a processor and a memory, the processing facility storing a set of instructions that, when executed, cause the e-commerce platform 100 to perform the e-commerce and support functions as described herein. The processing facility may be part of a server, client, network infrastructure, mobile computing platform, cloud computing platform, stationary computing platform, or other computing platform, and provide electronic connectivity and communications between and amongst the electronic components of the e-commerce platform 100, retailer devices 102, payment gateways 106, application development 108, channels 110, shipping providers 112, customer devices 150, POS devices 152, supplier devices 160, and the like. The e-commerce platform 100 may be implemented as a cloud computing service, a software as a service (SaaS), infrastructure as a service (IaaS), platform as a service (PaaS), desktop as a Service (DaaS), managed software as a service (MSaaS), mobile backend as a service (MBaaS), information technology management as a service (ITMaaS), and the like, such as in a software and delivery model in which software is licensed on a subscription basis and centrally hosted (e.g., accessed by users using a thin client via a web browser, accessed through by POS devices 152, and the like). In various embodiments, elements of the e-commerce platform 100 may be implemented to operate on various platforms and operating systems, such as iOS, Android, over the internet, and the like.
Reference Morris and Reference Starostenko are analogous prior art to the claimed invention because the references generally relate to field of inventory management. Further, said references are part of the same classification, i.e., G06Q10. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Starostenko, particularly the business backened (Starostenko: shown in [0037]), in the disclosure of Reference Morris, particularly in the system performs feature extraction on the normalized inventory data to convert the data into a set of inputs (e.g., features) suitable for training the machine learning model (Morris: shown in [0064]), in order to provide for a system that may support a great number of independently administered storefronts 139 and process a large volume of transactional data on a daily basis for a variety of products. Transactional data may include customer contact information, billing information, shipping information, information on products purchased, information on services rendered, and any other information associated with business through the e-commerce platform 100. In various embodiments, the e-commerce platform 100 may store this data in a data facility 134. The transactional data may be processed to produce analytics 132, which in turn may be provided to retailers or third-party commerce entities, such as providing consumer trends, marketing and sales insights, recommendations for improving sales, evaluation of customer behaviors, marketing and sales modeling, trends in fraud, and the like, related to online commerce, and provided through dashboard interfaces, through reports, and the like. The e-commerce platform 100 may store information about business and retailer transactions, and the data facility 134 may have many ways of enhancing, contributing, refining, and extracting data, where over time the collected data may enable improvements to aspects of the e-commerce platform 100 as taught by Reference Starostenko (see at least in [0045]), where upon the execution of the method and system of Reference Starostenko for reallocation of inventory from a supplier to a retailer (see at least in Abstract) so that the process of inventory management can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar inventory management field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Morris in view of Reference Starostenko, the results of the combination were predictable (MPEP 2143 A);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
dispatch business data to the interface service;
(Reference Morris shows in [0057] As shown in FIG. 3, the exemplary process begins with step 302, in which the system is configured to define categories of inventory events. In particular embodiments, the categories defined pertain to the type of inventory event (e.g., stockout or overstock). In these embodiments (and others), the type of inventory event is further categorized into one or more reasons for a stockout or overstock as discussed above in relation to FIG. 2. In certain embodiments, the categories may be defined manually by a user of the system via a user interface that allows the user to interact with the system. In various embodiments, the system may automatically define the categories of inventory events based on inventory data as may be received and processed by the system. [0058] At step 304, the system receives inventory data. In various embodiments, the inventory data may be manually entered into the system by a user (e.g., system administrator) via the user interface. In particular embodiments, the system may receive the inventory data from a third-party inventory management tool (e.g., an ERP tool). In these embodiments (and others), the system is configured to interface with various third-party applications via API integrations and/or various file sharing techniques (e.g., FTP transfers, cloud sharing, etc.). In one or more embodiments, if the inventory data is received from a third-party system, the data may be parsed and normalized prior to processing. In certain embodiments, the inventory data received by the system may be inventory data that was processed and output by the system and subsequently fed back into the system for additional processing. In at least one embodiment, the inventory data received by the system includes, but is not limited to: inventory type, product name, product description, quantity, location, days on hand, price, cost, number of units sold, last stockout event, last overstock event, lead time for replenishment, historical inventory data, and any other suitable information relevant to the systems and methods described herein. In one embodiment, the inventory data may be for a single user (e.g., a distributor). In another embodiment, the inventory data may be for a group of multiple users (e.g., several distributors). In certain embodiments, inventory data may be aggregated to assess various stockout and overstock trends and statistics (e.g., industry trends, geographic trends, etc.)
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
wherein the interface service is configured to:
(Reference Morris shows in [0057] As shown in FIG. 3, the exemplary process begins with step 302, in which the system is configured to define categories of inventory events. In particular embodiments, the categories defined pertain to the type of inventory event (e.g., stockout or overstock). In these embodiments (and others), the type of inventory event is further categorized into one or more reasons for a stockout or overstock as discussed above in relation to FIG. 2. In certain embodiments, the categories may be defined manually by a user of the system via a user interface that allows the user to interact with the system. In various embodiments, the system may automatically define the categories of inventory events based on inventory data as may be received and processed by the system. [0058] At step 304, the system receives inventory data. In various embodiments, the inventory data may be manually entered into the system by a user (e.g., system administrator) via the user interface. In particular embodiments, the system may receive the inventory data from a third-party inventory management tool (e.g., an ERP tool). In these embodiments (and others), the system is configured to interface with various third-party applications via API integrations and/or various file sharing techniques (e.g., FTP transfers, cloud sharing, etc.). In one or more embodiments, if the inventory data is received from a third-party system, the data may be parsed and normalized prior to processing. In certain embodiments, the inventory data received by the system may be inventory data that was processed and output by the system and subsequently fed back into the system for additional processing. In at least one embodiment, the inventory data received by the system includes, but is not limited to: inventory type, product name, product description, quantity, location, days on hand, price, cost, number of units sold, last stockout event, last overstock event, lead time for replenishment, historical inventory data, and any other suitable information relevant to the systems and methods described herein. In one embodiment, the inventory data may be for a single user (e.g., a distributor). In another embodiment, the inventory data may be for a group of multiple users (e.g., several distributors). In certain embodiments, inventory data may be aggregated to assess various stockout and overstock trends and statistics (e.g., industry trends, geographic trends, etc.)
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
perform data validation on the business data received from the business backend; and (Morris: [0060]: In particular embodiments, if the inventory data was not manually sorted, the system is configured to receive confirmation by a system administrator (e.g., a user) that the inventory data was appropriately and accurately sorted.)
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
transmit the business data to the persistent data storage and the message middleware
Reference Morris shows the ability to send messages or notifications: in [0045] In particular embodiments, the inventory system 100 may be configured to communicate with a vendor to adjust purchase orders based on the classification of identified stockouts or overstocks. Continuing with the above example, upon determining that the color-safe bleach was stocked out because replenishment purchase orders were made too late, the inventory system 100 initiates a communication with the vendor of the color-safe bleach to place an immediate order for the bleach and to adjust the timing of future purchase orders to eliminate the likelihood of a future stockout event for this item. In some embodiments, the inventory system 100 may communicate with the vendor 106 via email or direct messaging. In one or more embodiments, the inventory system 100 may integrate with the vendor's 106 inventory system to automatically place an order or to schedule/adjust future orders. In certain embodiments, the inventory system 100 is configured to issue a notification to the retail establishment 104 such that the retail establishment 104 can communicate with the vendor 106 to place an order or schedule/adjust future orders. Reference Morris does not explicitly show “middleware”, it is reasonably understood that the system that sends the message in Morris on [0045] has middleware that performs the task.
Reference Wang shows the above limitations in [0090] Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
Reference Morris, Reference Starostenko and Reference Wang are analogous prior art to the claimed invention because the references generally relate to field of inventory management. Further, said references are part of the same classification, i.e., G06Q10. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Wang, particularly the message middleware (Wang: shown in [0090]), in the disclosure of Reference Morris and Reference Starostenko, particularly in the ability to send messages or notifications (shown in [0045]), in order to provide for a system that system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet as taught by Reference Wang (see at least in [0090]), where upon the execution of the method and system of Reference Morris and Reference Starostenko for optimizing inventory levels using machine learning methodologies (Morris: see at least in Abstract) so that the process of inventory management can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar inventory management field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Morris and Reference Starostenko in view of Reference Wang, the results of the combination were predictable (MPEP 2143 A);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
wherein the persistent data storage is configured to:
store the business data received from the interface service as a reference for the calculation and analysis; and
(Reference Morris shows in [0057] As shown in FIG. 3, the exemplary process begins with step 302, in which the system is configured to define categories of inventory events. In particular embodiments, the categories defined pertain to the type of inventory event (e.g., stockout or overstock). In these embodiments (and others), the type of inventory event is further categorized into one or more reasons for a stockout or overstock as discussed above in relation to FIG. 2. In certain embodiments, the categories may be defined manually by a user of the system via a user interface that allows the user to interact with the system. In various embodiments, the system may automatically define the categories of inventory events based on inventory data as may be received and processed by the system. [0058] At step 304, the system receives inventory data. In various embodiments, the inventory data may be manually entered into the system by a user (e.g., system administrator) via the user interface. In particular embodiments, the system may receive the inventory data from a third-party inventory management tool (e.g., an ERP tool). In these embodiments (and others), the system is configured to interface with various third-party applications via API integrations and/or various file sharing techniques (e.g., FTP transfers, cloud sharing, etc.). In one or more embodiments, if the inventory data is received from a third-party system, the data may be parsed and normalized prior to processing. In certain embodiments, the inventory data received by the system may be inventory data that was processed and output by the system and subsequently fed back into the system for additional processing. In at least one embodiment, the inventory data received by the system includes, but is not limited to: inventory type, product name, product description, quantity, location, days on hand, price, cost, number of units sold, last stockout event, last overstock event, lead time for replenishment, historical inventory data, and any other suitable information relevant to the systems and methods described herein. In one embodiment, the inventory data may be for a single user (e.g., a distributor). In another embodiment, the inventory data may be for a group of multiple users (e.g., several distributors). In certain embodiments, inventory data may be aggregated to assess various stockout and overstock trends and statistics (e.g., industry trends, geographic trends, etc.
Reference Morris [0035] In one embodiment of the present systems and methods, inventory data is collected from a distribution establishment. In various embodiments, the inventory data may be collected by a third party inventory replenishment system (or other suitable system, such as an Enterprise Resource Planning (“ERP”) system). In certain embodiments, the inventory data may be manually entered into the system. In some embodiments, the collected data is processed and analyzed to identify past inventory issue events and categorize those events into one or more pre-defined categories. In particular embodiments, the processed data is then used to generate a machine learning model, such that new inventory issue events may be automatically identified and categorized (in some embodiments, the categorization can occur in real time). In these embodiments (and others), understanding the category of an inventory issue may allow for process adjustments to possibly prevent future inventory issues from occurring. [0037] Accordingly, as described above, aspects of the various embodiments described herein will train a given data model based on many prior inventory issue events and the data relating thereto. This often requires categorization of the prior inventory issue events (usually through manual categorization and analysis of the data). The model is trained based on these prior inventory issue events and the known reasons for the same to identify determining and probabilistic factors (root causes) that lead to a given inventory issue. Once trained, the model can be used for a given organization to track and identify the cause of any inventory issue event. [0043]: the inventory system 100 may determine that the retail establishment 104 is stocked out of a specialty brand of color-safe bleach. In various embodiments, the inventory system 100 may process and analyze the inventory information to determine that the color-safe bleach is stocked out because a replenishment purchase order was made too late to cover the intermediary demand. [0048]: the system may also include an analytics pipeline 202. In these embodiments (and others), the analytics pipeline 202 processes the data ingested from the source tables 200, 201 such that the data is compatible with the inventory system 100. In particular embodiments, the data is cleaned (e.g., normalized) to remove any extraneous information and reformatted into a standard form that the system can process and on which it can perform additional operations. In particular embodiments, feature extraction also occurs in the analytics pipeline 202. In various embodiments, feature extraction refers to the system converting the cleaned data into a set of features (e.g., inputs) suitable for the machine learning model. In various embodiments, the set of features may include PO issue date, PO receipt date, daily onhand units value, forecast quantity by day, vendor minimum, etc.. In at least one embodiment, the set of features include stockout and/or overstock data. In particular embodiments, and as will be further discussed below in relation to FIG. 3, the inventory data is sorted into one or more predefined categories. In certain embodiments, the one or more predefined categories generally comprise reasons for inventory stockout or overstock events as discussed above in relation to FIG. 1. In certain embodiments, the inventory data is manually sorted in the analytics pipeline 202. In at least one embodiment, the inventory data is automatically sorted based on one or more machine learning methodologies. [0054]: the classification engine 206 performs additional analysis on the classified inventory data. In these embodiments (and others), the classification engine 206 may assess the historical data of each inventory item and determine a recommended action for correcting the stockout and overstock events. In various embodiments, the system may recommend purchase orders, forecast adjustments, inventory transfers (between locations), price adjustments, and other similar recommendations In one embodiment, an exemplary recommendation may include the system paying freight costs for a particular vendor to reduce lost sales. In another embodiment, an exemplary recommendation may include the system employing additional analysis on proposed vendor deals to mitigate the risk of overstocks. [0060]: the classification engine is configured to analyze the inventory data (e.g., sales volume, customer size, customer purchase volume, time and date of sales, price of inventory, price changes, etc.) and determine the root cause of the stockout or overstock event based on its analysis. [0067] At step 408, the results produced by the trained model are evaluated and checked for accuracy and consistency. In some embodiments, the results produced by the trained model are evaluated using an evaluation set, which is generally a subset of the training datasets.);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
transmit data to the processor;
(Reference Morris: [0014] the present disclosure generally describe the system herein, further configured for: associating each of the plurality of items in the operational dataset with the respective category of the plurality of categories of stock events; and training the machine learning model based on the operational dataset of inventory data. In at least one embodiment, the present disclosure generally describe the system herein, wherein the efficacy is a measure of deviation between the pre-associated category of stock events to the estimated category of stock events, and an acceptable efficacy includes a margin of error below a predefined threshold for the deviation. In certain embodiments, the present disclosure generally describe the system herein, wherein the stock events are selected from the group including: stockouts, overstocks and appropriately stocked. In at least one embodiment, the present disclosure generally describe the system herein, wherein one or more respective categories of the plurality of categories are associated with one or more reasons for stock events. In certain embodiments, aspects of the present disclosure generally describe the system herein, wherein the plurality of categories include one of a first plurality of category subsets selected from the group including: stockouts; overstocks; and appropriately stocked. In particular embodiments, the present disclosure generally describe the system herein, wherein the first plurality of category subsets further include one of a second plurality of category subsets including the one or more reasons for stock events. In several embodiments, the present disclosure generally describe the system herein, wherein the one or more reasons for stock events are selected from the group including: replenishment orders for new items to be stocked with the particular entity made too late; one or more large unexpected customer sales depleted items stocked with the particular entity; undetected increases in demand of established items stocked with the particular entity; items stocked or to be stocked with the particular entity are low volume and difficult to forecast sales; purchase orders for items stocked or to be stocked are insufficient for strong seasonal pattern; purchase orders for items stocked or to be stocked are insufficient for promotions; late or short shipment of items to be stocked at particular location; new items stocked are selling more than forecasted; one or more items stocked were purchased in excess of forecast due to vendor minimums; one or more items stocked were purchased in excess of forecast due to vendor promotions; undetected decreases in demand of established items stocked with a particular entity; purchase orders for items stocked or to be stocked are packaged in quantities in excess of forecast; purchase orders for items stocked or to be stocked are overly ambitious for promotions; early or surplus shipment from vendor of items to be stocked at particular location; and new items stocked are selling less than expected. In some embodiments, aspects of the present disclosure generally describe the system herein, wherein the processor is further configured for: retrieving the stock event reason for each of the plurality of items in the operational dataset; and generating a recommendation for resolving the stock event reason. In various embodiments, the present disclosure generally describes the system herein, wherein the processor is further configured for: integrating with a third-party ordering system and initiating an inventory order based on the recommendation generated. In at least one embodiment, the present disclosure generally describe the system herein, wherein the output includes a printable report or a display on a graphical user interface of a computing device.);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
wherein the processor is configured to calculate overstock quantity and determine overstock type;
(Reference Morris: Abstract: The present systems and methods generally relate to optimizing inventory levels using machine learning methodologies. Using novel techniques, the present systems and methods can process and analyze inventory data to determine inventory items that are stocked out or overstocked and provide recommendations for mitigating these events, such that users can optimize their inventory levels with minimal manual intervention. For example, in various embodiments, the present systems and methods ingest inventory data, normalize and extract relevant portions of the inventory data, and sort the inventory data into one or more categories based on the root cause of any identified stockout or overstock events.
[0041] FIG. 1 depicts an example in which a retail establishment 104 employs the inventory system 100 disclosed herein to manage its inventory 108 and limit the likelihood of having stockout or overstock issues. In particular embodiments, the inventory system 100 is accessed via a computing device (e.g., smartphone, desktop computer, tablet computer, etc.). In certain embodiments, the inventory system 100 includes a database in which the retail establishment 104 can store information pertaining to its inventory 108. In various embodiments, the information stored may include, but is not limited to: type of inventory, product name, product description, quantity, location, days on hand, price, cost, number of units sold, last stockout event, last overstock event, lead time for replenishment, historical inventory data, and any other suitable information relevant to the systems and methods described herein. In certain embodiments, the inventory system 100 may obtain information pertaining to the retail establishment's 104 inventory from a third-party system 102. In particular embodiments, the third-party system 102 may be an Enterprise Resource Planning (“ERP”) system or other suitable inventory management system. In one or more embodiments, the inventory system 100 may be connected to the third-party system 102 via FTP, database sharing (e.g., SQL, virtual, etc.), custom API integration, or other suitable connectivity method. Further, as shown, the various components of this exemplary environment are operatively connected via one or more networks 110. [0043]: using the obtained inventory information, the inventory system 100 may identify inventory items that are stocked out or overstocked, at risk of being stocked out or overstocked, or have been stocked out or overstocked within a predetermined time period (e.g., within thirty days, ninety days, six months, etc.). In these embodiments (and others), using machine learning methodologies, the inventory system 100 may sort the identified stocked out or overstocked items into various categories of potential reasons (e.g., root causes) for which the items are stocked out or overstocked. For example, the inventory system 100 may determine that the retail establishment 104 is stocked out of a specialty brand of color-safe bleach. In various embodiments, the inventory system 100 may process and analyze the inventory information to determine that the color-safe bleach is stocked out because a replenishment purchase order was made too late to cover the intermediary demand. [0044]: the system may categorize causes of stockouts and overstocks into one or more categories based on contextual information associated with a stockout or overstock. In some embodiments, additional reasons for inventory issues may include severe weather issues, special events, etc. As will be understood and appreciated, other reasons for inventory issues (e.g., stockouts, overstocks, etc.) may exists in various environments; the reasons described herein are provided for illustrative and exemplary purposes only, and are not intended to limit the scope of the present disclosure in any way. In at least one embodiment, high-level reasons for a stockout or overstock may be broadly categorized as: 1) stockout or overstock caused by buyer error; 2) stockout or overstock caused by supplier error; and/or 3) stockout or overstock caused by forecasting error. In various embodiments, in addition to replenishment purchase orders being made too late (number one in the following list), additional reasons for stockouts may include, but are not limited to: 2) one or more large unexpected customer sales depleted inventory; 3) undetected increases in demand of established items; 4) items are low volume and difficult to forecast sales; 5) insufficient stock purchases for strong seasonal pattern; 6) insufficient stock purchases for promotions; 7) late or short shipment from vendor; and/or 8) new items are selling more than forecasted. Similarly, in at least one embodiment, the system may categorize overstocks into at least the following reasons: 1) excess inventory purchased due to Vendor Minimum; 2) Vendor offered “deal” or discount which caused excess purchase; 3) undetected decreases in demand of established items; 4) items are low volume and difficult to forecast sales; 5) Pack size (e.g., case of 100) caused excess purchase (e.g., only needed 3 units); 6) overly ambitious stock purchases for promotions; 7) early or surplus shipment from vendor; and/or 8) new items are selling less than expected. [0058]: In one or more embodiments, if the inventory data is received from a third-party system, the data may be parsed and normalized prior to processing. In certain embodiments, the inventory data received by the system may be inventory data that was processed and output by the system and subsequently fed back into the system for additional processing. In at least one embodiment, the inventory data received by the system includes, but is not limited to: inventory type, product name, product description, quantity, location, days on hand, price, cost, number of units sold, last stockout event, last overstock event, lead time for replenishment, historical inventory data, and any other suitable information relevant to the systems and methods described herein. In one embodiment, the inventory data may be for a single user (e.g., a distributor). In another embodiment, the inventory data may be for a group of multiple users (e.g., several distributors). In certain embodiments, inventory data may be aggregated to assess various stockout and overstock trends and statistics (e.g., industry trends, geographic trends, etc.);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
wherein the message middleware is configured to:
receive the business data from the interface service, and receive analysis results from the processor; and
(Reference Morris shows in [0057] As shown in FIG. 3, the exemplary process begins with step 302, in which the system is configured to define categories of inventory events. In particular embodiments, the categories defined pertain to the type of inventory event (e.g., stockout or overstock). In these embodiments (and others), the type of inventory event is further categorized into one or more reasons for a stockout or overstock as discussed above in relation to FIG. 2. In certain embodiments, the categories may be defined manually by a user of the system via a user interface that allows the user to interact with the system. In various embodiments, the system may automatically define the categories of inventory events based on inventory data as may be received and processed by the system. [0058] At step 304, the system receives inventory data. In various embodiments, the inventory data may be manually entered into the system by a user (e.g., system administrator) via the user interface. In particular embodiments, the system may receive the inventory data from a third-party inventory management tool (e.g., an ERP tool). In these embodiments (and others), the system is configured to interface with various third-party applications via API integrations and/or various file sharing techniques (e.g., FTP transfers, cloud sharing, etc.). In one or more embodiments, if the inventory data is received from a third-party system, the data may be parsed and normalized prior to processing. In certain embodiments, the inventory data received by the system may be inventory data that was processed and output by the system and subsequently fed back into the system for additional processing. In at least one embodiment, the inventory data received by the system includes, but is not limited to: inventory type, product name, product description, quantity, location, days on hand, price, cost, number of units sold, last stockout event, last overstock event, lead time for replenishment, historical inventory data, and any other suitable information relevant to the systems and methods described herein. In one embodiment, the inventory data may be for a single user (e.g., a distributor). In another embodiment, the inventory data may be for a group of multiple users (e.g., several distributors). In certain embodiments, inventory data may be aggregated to assess various stockout and overstock trends and statistics (e.g., industry trends, geographic trends, etc.
Reference Morris [0035] In one embodiment of the present systems and methods, inventory data is collected from a distribution establishment. In various embodiments, the inventory data may be collected by a third party inventory replenishment system (or other suitable system, such as an Enterprise Resource Planning (“ERP”) system). In certain embodiments, the inventory data may be manually entered into the system. In some embodiments, the collected data is processed and analyzed to identify past inventory issue events and categorize those events into one or more pre-defined categories. In particular embodiments, the processed data is then used to generate a machine learning model, such that new inventory issue events may be automatically identified and categorized (in some embodiments, the categorization can occur in real time). In these embodiments (and others), understanding the category of an inventory issue may allow for process adjustments to possibly prevent future inventory issues from occurring. [0037] Accordingly, as described above, aspects of the various embodiments described herein will train a given data model based on many prior inventory issue events and the data relating thereto. This often requires categorization of the prior inventory issue events (usually through manual categorization and analysis of the data). The model is trained based on these prior inventory issue events and the known reasons for the same to identify determining and probabilistic factors (root causes) that lead to a given inventory issue. Once trained, the model can be used for a given organization to track and identify the cause of any inventory issue event. [0043]: the inventory system 100 may determine that the retail establishment 104 is stocked out of a specialty brand of color-safe bleach. In various embodiments, the inventory system 100 may process and analyze the inventory information to determine that the color-safe bleach is stocked out because a replenishment purchase order was made too late to cover the intermediary demand. [0048]: the system may also include an analytics pipeline 202. In these embodiments (and others), the analytics pipeline 202 processes the data ingested from the source tables 200, 201 such that the data is compatible with the inventory system 100. In particular embodiments, the data is cleaned (e.g., normalized) to remove any extraneous information and reformatted into a standard form that the system can process and on which it can perform additional operations. In particular embodiments, feature extraction also occurs in the analytics pipeline 202. In various embodiments, feature extraction refers to the system converting the cleaned data into a set of features (e.g., inputs) suitable for the machine learning model. In various embodiments, the set of features may include PO issue date, PO receipt date, daily onhand units value, forecast quantity by day, vendor minimum, etc.. In at least one embodiment, the set of features include stockout and/or overstock data. In particular embodiments, and as will be further discussed below in relation to FIG. 3, the inventory data is sorted into one or more predefined categories. In certain embodiments, the one or more predefined categories generally comprise reasons for inventory stockout or overstock events as discussed above in relation to FIG. 1. In certain embodiments, the inventory data is manually sorted in the analytics pipeline 202. In at least one embodiment, the inventory data is automatically sorted based on one or more machine learning methodologies. [0054]: the classification engine 206 performs additional analysis on the classified inventory data. In these embodiments (and others), the classification engine 206 may assess the historical data of each inventory item and determine a recommended action for correcting the stockout and overstock events. In various embodiments, the system may recommend purchase orders, forecast adjustments, inventory transfers (between locations), price adjustments, and other similar recommendations In one embodiment, an exemplary recommendation may include the system paying freight costs for a particular vendor to reduce lost sales. In another embodiment, an exemplary recommendation may include the system employing additional analysis on proposed vendor deals to mitigate the risk of overstocks. [0060]: the classification engine is configured to analyze the inventory data (e.g., sales volume, customer size, customer purchase volume, time and date of sales, price of inventory, price changes, etc.) and determine the root cause of the stockout or overstock event based on its analysis. [0067] At step 408, the results produced by the trained model are evaluated and checked for accuracy and consistency. In some embodiments, the results produced by the trained model are evaluated using an evaluation set, which is generally a subset of the training datasets.);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
transmit the analysis results to interface service;
(Reference Morris shows in [0057] As shown in FIG. 3, the exemplary process begins with step 302, in which the system is configured to define categories of inventory events. In particular embodiments, the categories defined pertain to the type of inventory event (e.g., stockout or overstock). In these embodiments (and others), the type of inventory event is further categorized into one or more reasons for a stockout or overstock as discussed above in relation to FIG. 2. In certain embodiments, the categories may be defined manually by a user of the system via a user interface that allows the user to interact with the system. In various embodiments, the system may automatically define the categories of inventory events based on inventory data as may be received and processed by the system. [0058] At step 304, the system receives inventory data. In various embodiments, the inventory data may be manually entered into the system by a user (e.g., system administrator) via the user interface. In particular embodiments, the system may receive the inventory data from a third-party inventory management tool (e.g., an ERP tool). In these embodiments (and others), the system is configured to interface with various third-party applications via API integrations and/or various file sharing techniques (e.g., FTP transfers, cloud sharing, etc.). In one or more embodiments, if the inventory data is received from a third-party system, the data may be parsed and normalized prior to processing. In certain embodiments, the inventory data received by the system may be inventory data that was processed and output by the system and subsequently fed back into the system for additional processing. In at least one embodiment, the inventory data received by the system includes, but is not limited to: inventory type, product name, product description, quantity, location, days on hand, price, cost, number of units sold, last stockout event, last overstock event, lead time for replenishment, historical inventory data, and any other suitable information relevant to the systems and methods described herein. In one embodiment, the inventory data may be for a single user (e.g., a distributor). In another embodiment, the inventory data may be for a group of multiple users (e.g., several distributors). In certain embodiments, inventory data may be aggregated to assess various stockout and overstock trends and statistics (e.g., industry trends, geographic trends, etc.
Reference Morris [0035] In one embodiment of the present systems and methods, inventory data is collected from a distribution establishment. In various embodiments, the inventory data may be collected by a third party inventory replenishment system (or other suitable system, such as an Enterprise Resource Planning (“ERP”) system). In certain embodiments, the inventory data may be manually entered into the system. In some embodiments, the collected data is processed and analyzed to identify past inventory issue events and categorize those events into one or more pre-defined categories. In particular embodiments, the processed data is then used to generate a machine learning model, such that new inventory issue events may be automatically identified and categorized (in some embodiments, the categorization can occur in real time). In these embodiments (and others), understanding the category of an inventory issue may allow for process adjustments to possibly prevent future inventory issues from occurring. [0037] Accordingly, as described above, aspects of the various embodiments described herein will train a given data model based on many prior inventory issue events and the data relating thereto. This often requires categorization of the prior inventory issue events (usually through manual categorization and analysis of the data). The model is trained based on these prior inventory issue events and the known reasons for the same to identify determining and probabilistic factors (root causes) that lead to a given inventory issue. Once trained, the model can be used for a given organization to track and identify the cause of any inventory issue event. [0043]: the inventory system 100 may determine that the retail establishment 104 is stocked out of a specialty brand of color-safe bleach. In various embodiments, the inventory system 100 may process and analyze the inventory information to determine that the color-safe bleach is stocked out because a replenishment purchase order was made too late to cover the intermediary demand. [0048]: the system may also include an analytics pipeline 202. In these embodiments (and others), the analytics pipeline 202 processes the data ingested from the source tables 200, 201 such that the data is compatible with the inventory system 100. In particular embodiments, the data is cleaned (e.g., normalized) to remove any extraneous information and reformatted into a standard form that the system can process and on which it can perform additional operations. In particular embodiments, feature extraction also occurs in the analytics pipeline 202. In various embodiments, feature extraction refers to the system converting the cleaned data into a set of features (e.g., inputs) suitable for the machine learning model. In various embodiments, the set of features may include PO issue date, PO receipt date, daily onhand units value, forecast quantity by day, vendor minimum, etc.. In at least one embodiment, the set of features include stockout and/or overstock data. In particular embodiments, and as will be further discussed below in relation to FIG. 3, the inventory data is sorted into one or more predefined categories. In certain embodiments, the one or more predefined categories generally comprise reasons for inventory stockout or overstock events as discussed above in relation to FIG. 1. In certain embodiments, the inventory data is manually sorted in the analytics pipeline 202. In at least one embodiment, the inventory data is automatically sorted based on one or more machine learning methodologies. [0054]: the classification engine 206 performs additional analysis on the classified inventory data. In these embodiments (and others), the classification engine 206 may assess the historical data of each inventory item and determine a recommended action for correcting the stockout and overstock events. In various embodiments, the system may recommend purchase orders, forecast adjustments, inventory transfers (between locations), price adjustments, and other similar recommendations In one embodiment, an exemplary recommendation may include the system paying freight costs for a particular vendor to reduce lost sales. In another embodiment, an exemplary recommendation may include the system employing additional analysis on proposed vendor deals to mitigate the risk of overstocks. [0060]: the classification engine is configured to analyze the inventory data (e.g., sales volume, customer size, customer purchase volume, time and date of sales, price of inventory, price changes, etc.) and determine the root cause of the stockout or overstock event based on its analysis. [0067] At step 408, the results produced by the trained model are evaluated and checked for accuracy and consistency. In some embodiments, the results produced by the trained model are evaluated using an evaluation set, which is generally a subset of the training datasets.);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
wherein the interface service is configured to monitor message queue in the message middleware for updates regarding ongoing processes.
Reference Morris shows the ability to send messages or notifications: in [0045] In particular embodiments, the inventory system 100 may be configured to communicate with a vendor to adjust purchase orders based on the classification of identified stockouts or overstocks. Continuing with the above example, upon determining that the color-safe bleach was stocked out because replenishment purchase orders were made too late, the inventory system 100 initiates a communication with the vendor of the color-safe bleach to place an immediate order for the bleach and to adjust the timing of future purchase orders to eliminate the likelihood of a future stockout event for this item. In some embodiments, the inventory system 100 may communicate with the vendor 106 via email or direct messaging. In one or more embodiments, the inventory system 100 may integrate with the vendor's 106 inventory system to automatically place an order or to schedule/adjust future orders. In certain embodiments, the inventory system 100 is configured to issue a notification to the retail establishment 104 such that the retail establishment 104 can communicate with the vendor 106 to place an order or schedule/adjust future orders. Reference Morris does not explicitly show “middleware”, it is reasonably understood that the system that sends the message in Morris on [0045] has middleware that performs the task.
Reference Wang shows the above limitations in [0090] Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
Reference Morris, Reference Starostenko and Reference Wang are analogous prior art to the claimed invention because the references generally relate to field of inventory management. Further, said references are part of the same classification, i.e., G06Q10. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Wang, particularly the message middleware (Wang: shown in [0090]), in the disclosure of Reference Morris and Reference Starostenko, particularly in the ability to send messages or notifications (shown in [0045]), in order to provide for a system that system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet as taught by Reference Wang (see at least in [0090]), where upon the execution of the method and system of Reference Morris and Reference Starostenko for optimizing inventory levels using machine learning methodologies (Morris: see at least in Abstract) so that the process of inventory management can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar inventory management field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Morris and Reference Starostenko in view of Reference Wang, the results of the combination were predictable (MPEP 2143 A).
As per claims 2 and 11: Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
further comprising:
receiving, by the business backend, data from a business database, including information on one or more of production requirements, material inventory, bill of materials data, substitute material, and material priority.
References Morris shows “production requirements, material inventory” [0039] The present disclosure is not limited to, and does not distinguish between, any particular types of inventory. In one embodiment, the inventory can be raw materials or component parts. In another embodiment, the inventory can be finished products for retailing or wholesaling. In yet another embodiment, the inventory can be maintenance, repair, and operations goods. In yet another embodiment, the inventory can be works in in progress. In various embodiments, the inventory can be service inventory, transit inventory, or any other inventory that can be counted, tracked, and monitored.
As per claims 3 and 12: Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
further comprising parsing tag field, by the processor, during which tags or identifiers in the data received from the persistent data storage is analyzed.
Reference Morris shows: [0035] In one embodiment of the present systems and methods, inventory data is collected from a distribution establishment. In various embodiments, the inventory data may be collected by a third party inventory replenishment system (or other suitable system, such as an Enterprise Resource Planning (“ERP”) system). In certain embodiments, the inventory data may be manually entered into the system. In some embodiments, the collected data is processed and analyzed to identify past inventory issue events and categorize those events into one or more pre-defined categories. In particular embodiments, the processed data is then used to generate a machine learning model, such that new inventory issue events may be automatically identified and categorized (in some embodiments, the categorization can occur in real time). In these embodiments (and others), understanding the category of an inventory issue may allow for process adjustments to possibly prevent future inventory issues from occurring. [0037] Accordingly, as described above, aspects of the various embodiments described herein will train a given data model based on many prior inventory issue events and the data relating thereto. This often requires categorization of the prior inventory issue events (usually through manual categorization and analysis of the data). The model is trained based on these prior inventory issue events and the known reasons for the same to identify determining and probabilistic factors (root causes) that lead to a given inventory issue. Once trained, the model can be used for a given organization to track and identify the cause of any inventory issue event. [0038] Additionally, in further embodiments, the present system may integrate with traditional ordering systems or inventory control systems to automatically place orders on behalf of a given supplier, retailer, or other customer. For example, if the system identifies an immediate need for a given product because a stockout event is imminent, then rather than providing a recommendation to the end user and awaiting the user to manually create an order, the system can instead provide an instruction to the connected inventory control or ordering system to automatically place the determined order. In one embodiment, such automatic ordering can be controlled by various, predefined user parameters, such as only allowing orders within a certain size threshold, or under a given dollar amount, or of certain products, etc. These types of controls can be used to ensure large or unexpected orders are avoided. That said, use of real-time data monitoring and automatic ordering can help avoid many unwanted stockouts in a supplier or retailer environment. [0043] In at least one embodiment, using the obtained inventory information, the inventory system 100 may identify inventory items that are stocked out or overstocked, at risk of being stocked out or overstocked, or have been stocked out or overstocked within a predetermined time period (e.g., within thirty days, ninety days, six months, etc.). In these embodiments (and others), using machine learning methodologies, the inventory system 100 may sort the identified stocked out or overstocked items into various categories of potential reasons (e.g., root causes) for which the items are stocked out or overstocked. For example, the inventory system 100 may determine that the retail establishment 104 is stocked out of a specialty brand of color-safe bleach. In various embodiments, the inventory system 100 may process and analyze the inventory information to determine that the color-safe bleach is stocked out because a replenishment purchase order was made too late to cover the intermediary demand.
As per claims 4 and 13: Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
further comprising matching processing method, by the processor, during which an algorithm is selected.
Reference Morris shows [0050] In one or more embodiments, the output table 204 is transmitted to a classification engine 206 for further processing. In various embodiments, the classification engine 206 employs one or more machine learning methodologies to classify (e.g., sort) the inventory data according to the various categories of root causes of inventory stockout and overstock events. In certain embodiments, the machine learning methodologies employed by the classification engine 206 may include, but are not limited to: multiclass classification algorithms (e.g., multiclass logistic regression, multiclass neural network, multiclass decision forest, one-vs-all multiclass, multiclass boosted decision tree, etc.), latent Dirichlet allocation (LDA); term frequency-inverse document frequency (TF-IDF); k-means clustering; and any other algorithm suitable to perform the functions described herein. [0068] In various embodiments, at step 410, the system is configured to determine whether the model has been sufficiently trained or if the model needs to undergo further training. In particular embodiments, if the trained model returns a sorting accuracy within a predetermined confidence level or threshold (e.g., one percent, two percent, five percent, ten percent, etc.), then the results “match” and the system is configured to approve the model for operation and the process terminates. In these embodiments (and others), if the trained model returns a sorting accuracy outside of the predetermined confidence level, then the results do not match and the system is configured to cycle back to step 406 and retrain the machine learning model. In certain embodiments, this cycle will repeat itself until step 410 returns an indication that the trained model is approved for operation (i.e., returns a sorting accuracy within a predetermined threshold level). An acceptable threshold level can be determined by a system user or set as a default parameter of the system according to various preferences. In various embodiments, the model may be trained and generated using one or more categories of stockouts and overstocks, and one or more labels of exemplary stockouts and overstocks.
As per claims 5 and 14: Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
further comprising:
determining, by the processor, which inventory items should be prioritized for processing, redistribution, or optimization;
Reference Morris shows [0031] Briefly described, and according to one embodiment, aspects of the present disclosure generally relate to systems and methods for monitoring, managing, and optimizing inventory, and more specifically, to systems and methods for proactively identifying inventory issues and the underlying root cause of inventory issues. One such example of an inventory issue is a “stockout” which, as used herein, generally refers to depletion of a specific inventory item, for example, in a distribution environment, such that the item may be unavailable for purchase at the distribution environment for a period of time. Another example of an inventory issue is an “overstock,” which is typically defined differently for each organization but, as used herein, is generally considered more inventory than is needed for the foreseeable future. As may be used herein, a “stock event” generally refers to a stock out event (e.g., a stockout) and/or an overstock event (e.g., an overstock). [0040] Referring now to the figures, for the purposes of example and explanation of the fundamental processes and components of the disclosed systems and methods, reference is made to FIG. 1, which illustrates an exemplary, high-level overview of one embodiment of the systems and methods herein. As will be understood and appreciated, the exemplary, high-level overview shown in FIG. 1 represents merely one approach or embodiment of the present system, and other aspects are used according to various embodiments of the present system. In particular, FIG. 1 depicts a particular example where a retail establishment 104 uses an embodiment of the disclosed inventory system 100 to optimize inventory 108 received from a vendor 106. Further, FIG. 1 depicts how various systems in this environment interact in at least one embodiment of the systems and methods described herein. [0056]: an exemplary inventory optimization machine learning model initiation process 300 is shown, according to one embodiment of the present disclosure. More specifically, the embodiment shown in FIG. 3 shows a process for initiating an embodiment of the machine learning inventory optimization system described herein. In various embodiments, and as will be understood by a person having ordinary skill in the art, the steps and processes shown in FIG. 3 (and those of all other flowcharts and sequence diagrams shown and described herein) may operate concurrently and continuously, are generally asynchronous and independent, and are not necessarily performed in the order shown. [0063]: an exemplary inventory optimization machine learning model training subprocess 400 is shown, according to one embodiment of the present disclosure. In various embodiments, the exemplary process 400 begins at step 402, where the system is configured to store the results of the initial inventory sort performed at step 306 (from FIG. 3) in a database. [0074] Upon completion of the machine learning inventory optimization process, a user may desire to retrain the model using the inventory data processed and output by the system at step 508. In these embodiments (and others), at step 510, the system is configured to perform a check as to whether the user desires to retrain the model or terminate the process. If the user does not decide to retrain the model then the process will terminate. If the user decides to retrain the model with the inventory data as sorted and output at step 510, then the system is configured to cycle back to step 406 of FIG. 4 to retrain the machine learning model. In at least one embodiment, the system is configured to automatically retrain the model based on the resultant data set. In these embodiments (and others), the system is continually learning and improving its performance as more data is processed.
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
applying, by the processor, a set of rules to decide the next steps for processing the data; and
Reference Morris does not show the limitations above. Reference Starostenko shows [0062]: Checkout may delegate the calculation of taxes to a tax component and the calculation of shipping costs to a delivery component. A pricing component may enable retailers to create discount codes (e.g., “secret” strings that when entered on the checkout apply new prices to the items in the checkout). Discounts may be used by retailers to attract customers and assess the performance of marketing campaigns. Discounts and other custom price systems may be implemented on top of the same platform piece, such as through price rules (e.g., a set of prerequisites that when met imply a set of entitlements). For instance, prerequisites may be items such as “the order subtotal is greater than $100” or “the shipping cost is under $10”, and entitlements may be items such as “a 20% discount on the whole order” or “$10 off products X, Y, and Z”.
Reference Morris and Reference Starostenko are analogous prior art to the claimed invention because the references generally relate to field of inventory management. Further, said references are part of the same classification, i.e., G06Q10. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Starostenko, particularly the business backened (Starostenko: shown in [0037]), in the disclosure of Reference Morris, particularly in the system performs feature extraction on the normalized inventory data to convert the data into a set of inputs (e.g., features) suitable for training the machine learning model (Morris: shown in [0064]), in order to provide for a system that may support a great number of independently administered storefronts 139 and process a large volume of transactional data on a daily basis for a variety of products. Transactional data may include customer contact information, billing information, shipping information, information on products purchased, information on services rendered, and any other information associated with business through the e-commerce platform 100. In various embodiments, the e-commerce platform 100 may store this data in a data facility 134. The transactional data may be processed to produce analytics 132, which in turn may be provided to retailers or third-party commerce entities, such as providing consumer trends, marketing and sales insights, recommendations for improving sales, evaluation of customer behaviors, marketing and sales modeling, trends in fraud, and the like, related to online commerce, and provided through dashboard interfaces, through reports, and the like. The e-commerce platform 100 may store information about business and retailer transactions, and the data facility 134 may have many ways of enhancing, contributing, refining, and extracting data, where over time the collected data may enable improvements to aspects of the e-commerce platform 100 as taught by Reference Starostenko (see at least in [0045]), where upon the execution of the method and system of Reference Starostenko for reallocation of inventory from a supplier to a retailer (see at least in Abstract) so that the process of inventory management can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar inventory management field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Morris in view of Reference Starostenko, the results of the combination were predictable (MPEP 2143 A);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
using, by the processor, a linear programming model to optimize decisions about inventory levels and resource allocation to achieve cost-effectiveness or efficiency.
Reference Morris shows [0009] According to various embodiments, the present disclosure generally describes a system for managing product inventory levels including: a database that stores inventory data; and a non-transitory computer readable medium that controls a processor that performs the steps of: defining a plurality of categories of stock events; receiving a training dataset of inventory data, wherein the training dataset includes a plurality of items stocked or to be stocked with a particular entity; associating each of the plurality of items in the training dataset with a respective category of the plurality of categories of stock events; generating and training a machine learning model based on the training dataset of inventory data; receiving an evaluation dataset of inventory data, wherein the evaluation dataset includes a pre-associated category of stock events for each of the plurality of items; applying the machine learning model to the evaluation dataset of inventory data to generate an estimated category of stock events for each of the plurality of items; and comparing, for each of the plurality of items, the pre-associated category of stock events to the estimated category of stock events to determine an efficacy of the machine learning model. [0011] According to one or more embodiments, the present disclosure generally describes a method of managing product inventory levels including: receiving an operational dataset of inventory data, wherein the operational dataset includes a plurality of items stocked or to be stocked with a particular entity; retrieving a machine learning model, the machine learning model including a plurality of categories of stock events; applying the machine learning model to the operational dataset of inventory data to associate each of the plurality of items in the operational dataset with a respective category of the plurality of categories of stock events; and generating an output including results of the application of the machine learning model to the operational dataset. [0013] According to particular embodiments, the present disclosure generally describes a system for managing product inventory levels including: a database that stores inventory data; and a non-transitory computer readable medium that controls a processor that performs the steps of: receiving an operational dataset of inventory data, wherein the operational dataset includes a plurality of items stocked or to be stocked with a particular entity; retrieving a machine learning model, the machine learning model including a plurality of categories of stock events; applying the machine learning model to the operational dataset of inventory data to associate each of the plurality of items in the operational dataset with a respective category of the plurality of categories of stock events; and generating an output including results of the application of the machine learning model to the operational dataset. [0033] In one non-limiting discussion example, a need arises where an entity (e.g., a retailer, wholesaler, manufacturer, etc.) wants to improve its inventory performance. The entity may already use an inventory replenishment system to manage inventory levels, however, the systems and methods described herein can, in one embodiment, work with inventory replenishment systems to facilitate a better understanding and control of inventory issues, such that causes of the inventory issues are identified and can be corrected. [0050] In one or more embodiments, the output table 204 is transmitted to a classification engine 206 for further processing. In various embodiments, the classification engine 206 employs one or more machine learning methodologies to classify (e.g., sort) the inventory data according to the various categories of root causes of inventory stockout and overstock events. In certain embodiments, the machine learning methodologies employed by the classification engine 206 may include, but are not limited to: multiclass classification algorithms (e.g., multiclass logistic regression, multiclass neural network, multiclass decision forest, one-vs-all multiclass, multiclass boosted decision tree, etc.), latent Dirichlet allocation (LDA); term frequency-inverse document frequency (TF-IDF); k-means clustering; and any other algorithm suitable to perform the functions described herein. [0056] Turning now to FIG. 3, an exemplary inventory optimization machine learning model initiation process 300 is shown, according to one embodiment of the present disclosure. More specifically, the embodiment shown in FIG. 3 shows a process for initiating an embodiment of the machine learning inventory optimization system described herein. In various embodiments, and as will be understood by a person having ordinary skill in the art, the steps and processes shown in FIG. 3 (and those of all other flowcharts and sequence diagrams shown and described herein) may operate concurrently and continuously, are generally asynchronous and independent, and are not necessarily performed in the order shown. [0069] Now referring to FIG. 5, an exemplary inventory optimization machine learning model operational process 500 in operation is shown, according to one embodiment of the present disclosure. In various embodiments, the steps and processes described in FIG. 5 may occur after the machine learning model has been initiated (as shown and described in relation to FIG. 3) and trained (as shown and described in relation to FIG. 4).
As per claims 6 and 15: Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
further comprising:
performing, by the message middleware, one or more of queue management, message distribution, routing management, and asynchronous processing.
Reference Morris [0055] Applications 142 that utilize APIs may pull data on demand, but often they also need to have data pushed when updates occur. Update events may be implemented in a subscription model, such as for example, customer creation, product changes, or order cancelation. Update events may provide retailers with needed updates with respect to a changed state of the core commerce facility 136, such as for synchronizing a local database, notifying an external integration partner, and the like. Update events may enable this functionality without having to poll the core commerce facility 136 all the time to check for updates, such as through an update event subscription. In various embodiments, when a change related to an update event subscription occurs, the core commerce facility 136 may post a request, such as to a predefined callback URL. The body of this request may contain a new state of the object and a description of the action or event. Update event subscriptions may be created manually, in the administrator facility 114, or automatically (e.g., via the API). In various embodiments, update events may be queued and processed asynchronously from a state change that triggered them, which may produce an update event notification that is not distributed in real-time. [0104] Optionally, at operation 714, if the supplier's inventory is not sufficient to satisfy the determined geographic allocation, a notification may be generated to the supplier and/or the retailer (e.g., provided to the supplier device 160 and/or retailer device 102). The notification to the supplier may, for example, provide the supplier with information to adjust how the supplier's inventory should be geographically distributed. The notification to the retailer may, for example, provide the retailer with information to adjust the retailer's specified geographic allocation (if provided with the retailer's order). [0077] The marketing data 326 may include, for example, defined parameters for current or future marketing campaigns. Parameters defined for a given current or future marketing campaign may include, for example, a target demographic (e.g., target age group, target gender, target geographic region, etc.), marketing content (e.g., message content, promotions, etc.), marketing schedule (e.g., duration of campaign, planned phases of the campaign, etc.), distribution channel (e.g., via email, via social media, etc.), among other possible parameters. The parameters for a given marketing campaign may be provided to a marketing engine 340 of the e-commerce platform 100. The marketing engine 340 may then be used to conduct the marketing campaign according to the defined parameters. In some examples, the marketing engine 340 may also provide output that may be added to or used to update the marketing data 326. For example, the marketing engine 340 may recommend default parameter values that may be used by a retailer to define a marketing campaign in the retailer's marketing data 326.
As per claims 7 and 16: Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
further comprising:
receiving, by the message middleware, data from the interface service;
Reference Morris [0055] Applications 142 that utilize APIs may pull data on demand, but often they also need to have data pushed when updates occur. Update events may be implemented in a subscription model, such as for example, customer creation, product changes, or order cancelation. Update events may provide retailers with needed updates with respect to a changed state of the core commerce facility 136, such as for synchronizing a local database, notifying an external integration partner, and the like. Update events may enable this functionality without having to poll the core commerce facility 136 all the time to check for updates, such as through an update event subscription. In various embodiments, when a change related to an update event subscription occurs, the core commerce facility 136 may post a request, such as to a predefined callback URL. The body of this request may contain a new state of the object and a description of the action or event. Update event subscriptions may be created manually, in the administrator facility 114, or automatically (e.g., via the API). In various embodiments, update events may be queued and processed asynchronously from a state change that triggered them, which may produce an update event notification that is not distributed in real-time. [0104] Optionally, at operation 714, if the supplier's inventory is not sufficient to satisfy the determined geographic allocation, a notification may be generated to the supplier and/or the retailer (e.g., provided to the supplier device 160 and/or retailer device 102). The notification to the supplier may, for example, provide the supplier with information to adjust how the supplier's inventory should be geographically distributed. The notification to the retailer may, for example, provide the retailer with information to adjust the retailer's specified geographic allocation (if provided with the retailer's order). [0077] The marketing data 326 may include, for example, defined parameters for current or future marketing campaigns. Parameters defined for a given current or future marketing campaign may include, for example, a target demographic (e.g., target age group, target gender, target geographic region, etc.), marketing content (e.g., message content, promotions, etc.), marketing schedule (e.g., duration of campaign, planned phases of the campaign, etc.), distribution channel (e.g., via email, via social media, etc.), among other possible parameters. The parameters for a given marketing campaign may be provided to a marketing engine 340 of the e-commerce platform 100. The marketing engine 340 may then be used to conduct the marketing campaign according to the defined parameters. In some examples, the marketing engine 340 may also provide output that may be added to or used to update the marketing data 326. For example, the marketing engine 340 may recommend default parameter values that may be used by a retailer to define a marketing campaign in the retailer's marketing data 326.
Reference Morris shows the ability to send messages or notifications: in [0045] In particular embodiments, the inventory system 100 may be configured to communicate with a vendor to adjust purchase orders based on the classification of identified stockouts or overstocks. Continuing with the above example, upon determining that the color-safe bleach was stocked out because replenishment purchase orders were made too late, the inventory system 100 initiates a communication with the vendor of the color-safe bleach to place an immediate order for the bleach and to adjust the timing of future purchase orders to eliminate the likelihood of a future stockout event for this item. In some embodiments, the inventory system 100 may communicate with the vendor 106 via email or direct messaging. In one or more embodiments, the inventory system 100 may integrate with the vendor's 106 inventory system to automatically place an order or to schedule/adjust future orders. In certain embodiments, the inventory system 100 is configured to issue a notification to the retail establishment 104 such that the retail establishment 104 can communicate with the vendor 106 to place an order or schedule/adjust future orders. Reference Morris does not explicitly show “middleware”, it is reasonably understood that the system that sends the message in Morris on [0045] has middleware that performs the task.
Reference Wang shows the above limitations in [0090] Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
Reference Morris, Reference Starostenko and Reference Wang are analogous prior art to the claimed invention because the references generally relate to field of inventory management. Further, said references are part of the same classification, i.e., G06Q10. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Wang, particularly the message middleware (Wang: shown in [0090]), in the disclosure of Reference Morris and Reference Starostenko, particularly in the ability to send messages or notifications (shown in [0045]), in order to provide for a system that system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet as taught by Reference Wang (see at least in [0090]), where upon the execution of the method and system of Reference Morris and Reference Starostenko for optimizing inventory levels using machine learning methodologies (Morris: see at least in Abstract) so that the process of inventory management can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar inventory management field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Morris and Reference Starostenko in view of Reference Wang, the results of the combination were predictable (MPEP 2143 A);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
placing, by the message middleware, the data in a first message queue;
reading, by the processor, data from the first message queue managed by the middleware;
transmitting, by the processor, the analysis results to the message middleware;
Reference Morris [0055] Applications 142 that utilize APIs may pull data on demand, but often they also need to have data pushed when updates occur. Update events may be implemented in a subscription model, such as for example, customer creation, product changes, or order cancelation. Update events may provide retailers with needed updates with respect to a changed state of the core commerce facility 136, such as for synchronizing a local database, notifying an external integration partner, and the like. Update events may enable this functionality without having to poll the core commerce facility 136 all the time to check for updates, such as through an update event subscription. In various embodiments, when a change related to an update event subscription occurs, the core commerce facility 136 may post a request, such as to a predefined callback URL. The body of this request may contain a new state of the object and a description of the action or event. Update event subscriptions may be created manually, in the administrator facility 114, or automatically (e.g., via the API). In various embodiments, update events may be queued and processed asynchronously from a state change that triggered them, which may produce an update event notification that is not distributed in real-time. [0104] Optionally, at operation 714, if the supplier's inventory is not sufficient to satisfy the determined geographic allocation, a notification may be generated to the supplier and/or the retailer (e.g., provided to the supplier device 160 and/or retailer device 102). The notification to the supplier may, for example, provide the supplier with information to adjust how the supplier's inventory should be geographically distributed. The notification to the retailer may, for example, provide the retailer with information to adjust the retailer's specified geographic allocation (if provided with the retailer's order). [0077] The marketing data 326 may include, for example, defined parameters for current or future marketing campaigns. Parameters defined for a given current or future marketing campaign may include, for example, a target demographic (e.g., target age group, target gender, target geographic region, etc.), marketing content (e.g., message content, promotions, etc.), marketing schedule (e.g., duration of campaign, planned phases of the campaign, etc.), distribution channel (e.g., via email, via social media, etc.), among other possible parameters. The parameters for a given marketing campaign may be provided to a marketing engine 340 of the e-commerce platform 100. The marketing engine 340 may then be used to conduct the marketing campaign according to the defined parameters. In some examples, the marketing engine 340 may also provide output that may be added to or used to update the marketing data 326. For example, the marketing engine 340 may recommend default parameter values that may be used by a retailer to define a marketing campaign in the retailer's marketing data 326.
Reference Morris shows the ability to send messages or notifications: in [0045] In particular embodiments, the inventory system 100 may be configured to communicate with a vendor to adjust purchase orders based on the classification of identified stockouts or overstocks. Continuing with the above example, upon determining that the color-safe bleach was stocked out because replenishment purchase orders were made too late, the inventory system 100 initiates a communication with the vendor of the color-safe bleach to place an immediate order for the bleach and to adjust the timing of future purchase orders to eliminate the likelihood of a future stockout event for this item. In some embodiments, the inventory system 100 may communicate with the vendor 106 via email or direct messaging. In one or more embodiments, the inventory system 100 may integrate with the vendor's 106 inventory system to automatically place an order or to schedule/adjust future orders. In certain embodiments, the inventory system 100 is configured to issue a notification to the retail establishment 104 such that the retail establishment 104 can communicate with the vendor 106 to place an order or schedule/adjust future orders. Reference Morris does not explicitly show “middleware”, it is reasonably understood that the system that sends the message in Morris on [0045] has middleware that performs the task.
Reference Wang shows the above limitations in [0090] Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
Reference Morris, Reference Starostenko and Reference Wang are analogous prior art to the claimed invention because the references generally relate to field of inventory management. Further, said references are part of the same classification, i.e., G06Q10. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Wang, particularly the message middleware (Wang: shown in [0090]), in the disclosure of Reference Morris and Reference Starostenko, particularly in the ability to send messages or notifications (shown in [0045]), in order to provide for a system that system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet as taught by Reference Wang (see at least in [0090]), where upon the execution of the method and system of Reference Morris and Reference Starostenko for optimizing inventory levels using machine learning methodologies (Morris: see at least in Abstract) so that the process of inventory management can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar inventory management field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Morris and Reference Starostenko in view of Reference Wang, the results of the combination were predictable (MPEP 2143 A);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
placing, by the message middleware, the analysis results in a second message queue; and
obtaining, by the interface service, the analysis results from the second message queue.
Reference Morris [0055] Applications 142 that utilize APIs may pull data on demand, but often they also need to have data pushed when updates occur. Update events may be implemented in a subscription model, such as for example, customer creation, product changes, or order cancelation. Update events may provide retailers with needed updates with respect to a changed state of the core commerce facility 136, such as for synchronizing a local database, notifying an external integration partner, and the like. Update events may enable this functionality without having to poll the core commerce facility 136 all the time to check for updates, such as through an update event subscription. In various embodiments, when a change related to an update event subscription occurs, the core commerce facility 136 may post a request, such as to a predefined callback URL. The body of this request may contain a new state of the object and a description of the action or event. Update event subscriptions may be created manually, in the administrator facility 114, or automatically (e.g., via the API). In various embodiments, update events may be queued and processed asynchronously from a state change that triggered them, which may produce an update event notification that is not distributed in real-time. [0104] Optionally, at operation 714, if the supplier's inventory is not sufficient to satisfy the determined geographic allocation, a notification may be generated to the supplier and/or the retailer (e.g., provided to the supplier device 160 and/or retailer device 102). The notification to the supplier may, for example, provide the supplier with information to adjust how the supplier's inventory should be geographically distributed. The notification to the retailer may, for example, provide the retailer with information to adjust the retailer's specified geographic allocation (if provided with the retailer's order). [0077] The marketing data 326 may include, for example, defined parameters for current or future marketing campaigns. Parameters defined for a given current or future marketing campaign may include, for example, a target demographic (e.g., target age group, target gender, target geographic region, etc.), marketing content (e.g., message content, promotions, etc.), marketing schedule (e.g., duration of campaign, planned phases of the campaign, etc.), distribution channel (e.g., via email, via social media, etc.), among other possible parameters. The parameters for a given marketing campaign may be provided to a marketing engine 340 of the e-commerce platform 100. The marketing engine 340 may then be used to conduct the marketing campaign according to the defined parameters. In some examples, the marketing engine 340 may also provide output that may be added to or used to update the marketing data 326. For example, the marketing engine 340 may recommend default parameter values that may be used by a retailer to define a marketing campaign in the retailer's marketing data 326.
Reference Morris shows the ability to send messages or notifications: in [0045] In particular embodiments, the inventory system 100 may be configured to communicate with a vendor to adjust purchase orders based on the classification of identified stockouts or overstocks. Continuing with the above example, upon determining that the color-safe bleach was stocked out because replenishment purchase orders were made too late, the inventory system 100 initiates a communication with the vendor of the color-safe bleach to place an immediate order for the bleach and to adjust the timing of future purchase orders to eliminate the likelihood of a future stockout event for this item. In some embodiments, the inventory system 100 may communicate with the vendor 106 via email or direct messaging. In one or more embodiments, the inventory system 100 may integrate with the vendor's 106 inventory system to automatically place an order or to schedule/adjust future orders. In certain embodiments, the inventory system 100 is configured to issue a notification to the retail establishment 104 such that the retail establishment 104 can communicate with the vendor 106 to place an order or schedule/adjust future orders. Reference Morris does not explicitly show “middleware”, it is reasonably understood that the system that sends the message in Morris on [0045] has middleware that performs the task.
Reference Wang shows the above limitations in [0090] Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
Reference Morris, Reference Starostenko and Reference Wang are analogous prior art to the claimed invention because the references generally relate to field of inventory management. Further, said references are part of the same classification, i.e., G06Q10. Lastly, said references are filed before the effective filing date of the instant application; hence, said references are analogous prior-art references.
It would have been obvious to one of ordinary skill in the art before the effective filing date of this application for AIA to provide the teachings of Reference Wang, particularly the message middleware (Wang: shown in [0090]), in the disclosure of Reference Morris and Reference Starostenko, particularly in the ability to send messages or notifications (shown in [0045]), in order to provide for a system that system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet as taught by Reference Wang (see at least in [0090]), where upon the execution of the method and system of Reference Morris and Reference Starostenko for optimizing inventory levels using machine learning methodologies (Morris: see at least in Abstract) so that the process of inventory management can be made more efficient and effective.
Further, the claimed invention is merely a combination of old elements in a similar inventory management field of endeavor, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Reference Morris and Reference Starostenko in view of Reference Wang, the results of the combination were predictable (MPEP 2143 A).
As per claims 8 and 17: Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
further comprising:
pushing, by the interface service, results to the user interface terminal for display; and
(Reference Morris shows in [0057] As shown in FIG. 3, the exemplary process begins with step 302, in which the system is configured to define categories of inventory events. In particular embodiments, the categories defined pertain to the type of inventory event (e.g., stockout or overstock). In these embodiments (and others), the type of inventory event is further categorized into one or more reasons for a stockout or overstock as discussed above in relation to FIG. 2. In certain embodiments, the categories may be defined manually by a user of the system via a user interface that allows the user to interact with the system. In various embodiments, the system may automatically define the categories of inventory events based on inventory data as may be received and processed by the system. [0058] At step 304, the system receives inventory data. In various embodiments, the inventory data may be manually entered into the system by a user (e.g., system administrator) via the user interface. In particular embodiments, the system may receive the inventory data from a third-party inventory management tool (e.g., an ERP tool). In these embodiments (and others), the system is configured to interface with various third-party applications via API integrations and/or various file sharing techniques (e.g., FTP transfers, cloud sharing, etc.). In one or more embodiments, if the inventory data is received from a third-party system, the data may be parsed and normalized prior to processing. In certain embodiments, the inventory data received by the system may be inventory data that was processed and output by the system and subsequently fed back into the system for additional processing. In at least one embodiment, the inventory data received by the system includes, but is not limited to: inventory type, product name, product description, quantity, location, days on hand, price, cost, number of units sold, last stockout event, last overstock event, lead time for replenishment, historical inventory data, and any other suitable information relevant to the systems and methods described herein. In one embodiment, the inventory data may be for a single user (e.g., a distributor). In another embodiment, the inventory data may be for a group of multiple users (e.g., several distributors). In certain embodiments, inventory data may be aggregated to assess various stockout and overstock trends and statistics (e.g., industry trends, geographic trends, etc.
Reference Morris [0035] In one embodiment of the present systems and methods, inventory data is collected from a distribution establishment. In various embodiments, the inventory data may be collected by a third party inventory replenishment system (or other suitable system, such as an Enterprise Resource Planning (“ERP”) system). In certain embodiments, the inventory data may be manually entered into the system. In some embodiments, the collected data is processed and analyzed to identify past inventory issue events and categorize those events into one or more pre-defined categories. In particular embodiments, the processed data is then used to generate a machine learning model, such that new inventory issue events may be automatically identified and categorized (in some embodiments, the categorization can occur in real time). In these embodiments (and others), understanding the category of an inventory issue may allow for process adjustments to possibly prevent future inventory issues from occurring. [0037] Accordingly, as described above, aspects of the various embodiments described herein will train a given data model based on many prior inventory issue events and the data relating thereto. This often requires categorization of the prior inventory issue events (usually through manual categorization and analysis of the data). The model is trained based on these prior inventory issue events and the known reasons for the same to identify determining and probabilistic factors (root causes) that lead to a given inventory issue. Once trained, the model can be used for a given organization to track and identify the cause of any inventory issue event. [0043]: the inventory system 100 may determine that the retail establishment 104 is stocked out of a specialty brand of color-safe bleach. In various embodiments, the inventory system 100 may process and analyze the inventory information to determine that the color-safe bleach is stocked out because a replenishment purchase order was made too late to cover the intermediary demand. [0048]: the system may also include an analytics pipeline 202. In these embodiments (and others), the analytics pipeline 202 processes the data ingested from the source tables 200, 201 such that the data is compatible with the inventory system 100. In particular embodiments, the data is cleaned (e.g., normalized) to remove any extraneous information and reformatted into a standard form that the system can process and on which it can perform additional operations. In particular embodiments, feature extraction also occurs in the analytics pipeline 202. In various embodiments, feature extraction refers to the system converting the cleaned data into a set of features (e.g., inputs) suitable for the machine learning model. In various embodiments, the set of features may include PO issue date, PO receipt date, daily onhand units value, forecast quantity by day, vendor minimum, etc.. In at least one embodiment, the set of features include stockout and/or overstock data. In particular embodiments, and as will be further discussed below in relation to FIG. 3, the inventory data is sorted into one or more predefined categories. In certain embodiments, the one or more predefined categories generally comprise reasons for inventory stockout or overstock events as discussed above in relation to FIG. 1. In certain embodiments, the inventory data is manually sorted in the analytics pipeline 202. In at least one embodiment, the inventory data is automatically sorted based on one or more machine learning methodologies. [0054]: the classification engine 206 performs additional analysis on the classified inventory data. In these embodiments (and others), the classification engine 206 may assess the historical data of each inventory item and determine a recommended action for correcting the stockout and overstock events. In various embodiments, the system may recommend purchase orders, forecast adjustments, inventory transfers (between locations), price adjustments, and other similar recommendations In one embodiment, an exemplary recommendation may include the system paying freight costs for a particular vendor to reduce lost sales. In another embodiment, an exemplary recommendation may include the system employing additional analysis on proposed vendor deals to mitigate the risk of overstocks. [0060]: the classification engine is configured to analyze the inventory data (e.g., sales volume, customer size, customer purchase volume, time and date of sales, price of inventory, price changes, etc.) and determine the root cause of the stockout or overstock event based on its analysis. [0067] At step 408, the results produced by the trained model are evaluated and checked for accuracy and consistency. In some embodiments, the results produced by the trained model are evaluated using an evaluation set, which is generally a subset of the training datasets.);
Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
receiving, by a user interface terminal, calculation requests and display results of overstocked inventory management.
(Reference Morris shows in [0057] As shown in FIG. 3, the exemplary process begins with step 302, in which the system is configured to define categories of inventory events. In particular embodiments, the categories defined pertain to the type of inventory event (e.g., stockout or overstock). In these embodiments (and others), the type of inventory event is further categorized into one or more reasons for a stockout or overstock as discussed above in relation to FIG. 2. In certain embodiments, the categories may be defined manually by a user of the system via a user interface that allows the user to interact with the system. In various embodiments, the system may automatically define the categories of inventory events based on inventory data as may be received and processed by the system. [0058] At step 304, the system receives inventory data. In various embodiments, the inventory data may be manually entered into the system by a user (e.g., system administrator) via the user interface. In particular embodiments, the system may receive the inventory data from a third-party inventory management tool (e.g., an ERP tool). In these embodiments (and others), the system is configured to interface with various third-party applications via API integrations and/or various file sharing techniques (e.g., FTP transfers, cloud sharing, etc.). In one or more embodiments, if the inventory data is received from a third-party system, the data may be parsed and normalized prior to processing. In certain embodiments, the inventory data received by the system may be inventory data that was processed and output by the system and subsequently fed back into the system for additional processing. In at least one embodiment, the inventory data received by the system includes, but is not limited to: inventory type, product name, product description, quantity, location, days on hand, price, cost, number of units sold, last stockout event, last overstock event, lead time for replenishment, historical inventory data, and any other suitable information relevant to the systems and methods described herein. In one embodiment, the inventory data may be for a single user (e.g., a distributor). In another embodiment, the inventory data may be for a group of multiple users (e.g., several distributors). In certain embodiments, inventory data may be aggregated to assess various stockout and overstock trends and statistics (e.g., industry trends, geographic trends, etc.
Reference Morris [0035] In one embodiment of the present systems and methods, inventory data is collected from a distribution establishment. In various embodiments, the inventory data may be collected by a third party inventory replenishment system (or other suitable system, such as an Enterprise Resource Planning (“ERP”) system). In certain embodiments, the inventory data may be manually entered into the system. In some embodiments, the collected data is processed and analyzed to identify past inventory issue events and categorize those events into one or more pre-defined categories. In particular embodiments, the processed data is then used to generate a machine learning model, such that new inventory issue events may be automatically identified and categorized (in some embodiments, the categorization can occur in real time). In these embodiments (and others), understanding the category of an inventory issue may allow for process adjustments to possibly prevent future inventory issues from occurring. [0037] Accordingly, as described above, aspects of the various embodiments described herein will train a given data model based on many prior inventory issue events and the data relating thereto. This often requires categorization of the prior inventory issue events (usually through manual categorization and analysis of the data). The model is trained based on these prior inventory issue events and the known reasons for the same to identify determining and probabilistic factors (root causes) that lead to a given inventory issue. Once trained, the model can be used for a given organization to track and identify the cause of any inventory issue event. [0043]: the inventory system 100 may determine that the retail establishment 104 is stocked out of a specialty brand of color-safe bleach. In various embodiments, the inventory system 100 may process and analyze the inventory information to determine that the color-safe bleach is stocked out because a replenishment purchase order was made too late to cover the intermediary demand. [0048]: the system may also include an analytics pipeline 202. In these embodiments (and others), the analytics pipeline 202 processes the data ingested from the source tables 200, 201 such that the data is compatible with the inventory system 100. In particular embodiments, the data is cleaned (e.g., normalized) to remove any extraneous information and reformatted into a standard form that the system can process and on which it can perform additional operations. In particular embodiments, feature extraction also occurs in the analytics pipeline 202. In various embodiments, feature extraction refers to the system converting the cleaned data into a set of features (e.g., inputs) suitable for the machine learning model. In various embodiments, the set of features may include PO issue date, PO receipt date, daily onhand units value, forecast quantity by day, vendor minimum, etc.. In at least one embodiment, the set of features include stockout and/or overstock data. In particular embodiments, and as will be further discussed below in relation to FIG. 3, the inventory data is sorted into one or more predefined categories. In certain embodiments, the one or more predefined categories generally comprise reasons for inventory stockout or overstock events as discussed above in relation to FIG. 1. In certain embodiments, the inventory data is manually sorted in the analytics pipeline 202. In at least one embodiment, the inventory data is automatically sorted based on one or more machine learning methodologies. [0054]: the classification engine 206 performs additional analysis on the classified inventory data. In these embodiments (and others), the classification engine 206 may assess the historical data of each inventory item and determine a recommended action for correcting the stockout and overstock events. In various embodiments, the system may recommend purchase orders, forecast adjustments, inventory transfers (between locations), price adjustments, and other similar recommendations In one embodiment, an exemplary recommendation may include the system paying freight costs for a particular vendor to reduce lost sales. In another embodiment, an exemplary recommendation may include the system employing additional analysis on proposed vendor deals to mitigate the risk of overstocks. [0060]: the classification engine is configured to analyze the inventory data (e.g., sales volume, customer size, customer purchase volume, time and date of sales, price of inventory, price changes, etc.) and determine the root cause of the stockout or overstock event based on its analysis. [0067] At step 408, the results produced by the trained model are evaluated and checked for accuracy and consistency. In some embodiments, the results produced by the trained model are evaluated using an evaluation set, which is generally a subset of the training datasets.).
As per claims 9 and 18: Regarding the claim limitations below, Reference Morris in view of Starostenko and Wang shows:
further comprising performing, by a container engine, one or more of container construction, container orchestration, and application management.
Reference Morris shows [0066] An order assessment component may implement a business process retailers use to ensure orders are suitable for fulfillment before actually fulfilling them. Orders may be fraudulent, require verification (e.g., ID checking), have a payment method which requires the retailer to wait to make sure they will receive their funds, and the like. Risks and recommendations may be persisted in an order risk model. Order risks may be generated from a fraud detection tool, submitted by a third-party through an order risk API, and the like. Before proceeding to fulfillment, the retailer may need to capture the payment information (e.g., credit card information) or wait to receive it (e.g., via a bank transfer, check, and the like) and mark the order as paid. The retailer may now prepare the products for delivery. In various embodiments, this business process may be implemented by a fulfillment component. The fulfillment component may group the line items of the order into a logical fulfillment unit of work based on an inventory location and fulfillment service. The retailer may assess the order, adjust the unit of work, and trigger the relevant fulfillment services, such as through a manual fulfillment service (e.g., at retailer managed locations) used when the retailer picks and packs the products in a box, purchase a shipping label and input its tracking number, or just mark the item as fulfilled. A custom fulfillment service may send an email (e.g., a location that does not provide an API connection). An API fulfillment service may trigger a third party, where the third-party application creates a fulfillment record. A legacy fulfillment service may trigger a custom API call from the core commerce facility 136 to a third party (e.g., fulfillment by Amazon). A gift card fulfillment service may provision (e.g., generating a number) and activate a gift card. Retailers may use an order printer application to print packing slips. The fulfillment process may be executed when the items are packed in the box and ready for shipping, shipped, tracked, delivered, verified as received by the customer, and the like.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
NPL Reference:
W. Yang, Y. Chen, Y. -C. Chen and K. -C. Yeh, "Intelligent Agent-Based Predict System With Cloud Computing for Enterprise Service Platform in IoT Environment," in IEEE Access, vol. 9, pp. 11843-11871, 2021, doi: 10.1109/ACCESS.2021.3049256.
This reference discloses if the product supply shortage occurs during the sales period, customers will turn to other companies, so the enterprise lose the sales opportunity. If the enterprise can predict product demands, and manages the product sales by using the supply chain management prediction system to improve the bottleneck of the inventory, the hot sales product can have more critical time utilization, and the inventory status can be reflected quickly by Internet of Things (IoT). To overcome the problem that the replenishment model cannot show the actual quantity of products on the store shelves, in the paper, we propose an intelligent agent-based prediction system, which serves as a framework to construct an integrated prediction system through the use of radio frequency identification (RFID) technology to design the intelligent product prediction shelf to extract product messages, and the service oriented architecture to develop prediction information to recommend products to the customer. The result of the paper proposes an agent-based cloud computing service platform in IoT and intelligent agents with SOA as backend cloud services. To build a prototype prediction system with performance analysis, it can be proved that the prediction system architecture for intelligent agent-based prediction system could improve operation performance and effectively enhance customer service quality for hot sale products.
Foreign Reference:
(CN 108269033 A) Qiu et al. The invention claims a production line material distributing system, comprising: producing warehouse, conveying device, material of the production warehouse computer system; storing the product, the computer system obtains the production process data and the production plan; the production process data comprises the product of the material information; calculating the first number of the obtained material for producing a product according to material information and production planning computer system; the computer system is production warehouse is set not less than the safety stock threshold of the first number; after obtaining material from the production warehouse transport device. the computer system calculates the production material number inventory in the warehouse, when the material quantity of the inventory below a safety stock threshold, computer system request the supplementary material; and transportation device, obtaining material from the production warehouse and transported to different stations of the production line along a preset path. The invention also claims a production line material distributing method and a production repository. The invention simplifies the operation process and improves the operation efficiency.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NANCY PRASAD whose telephone number is (571)270-3265. The examiner can normally be reached M-F: 8:00 AM - 4:30 PM 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, Patricia Munson can be reached at (571)270-5396. 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 Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/N.N.P/Examiner, Art Unit 3624 /PATRICIA H MUNSON/Supervisory Patent Examiner, Art Unit 3624