DETAILED ACTION
This Non-Final Office action is in response to Applicant’s RCE on 02/24/2026. Claims 1-8 and 21-32 are pending. The effective filing date of the claimed invention is 5/11/2023.
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 .
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 29-32 are rejected under 35 USC 101 as the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because claim 29 does not include “a non-transitory computer-readable medium . . . .” See In re Nuijten. The examiner recommends adding the underlined non-transitory language. Appropriate correction is required.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-5, 21-25, and 29-31 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pat. Pub. No. 2013/0211977 (WAREHOUSE MANAGEMENT SYSTEM) to Lyon et al. (“Lyon”) in view of U.S. Pat. Pub. No. 2016/0320943 (CONTROL OF ICON MOVEMENT ON GUI) to Kim (“Kim”) in view of U.S. Pat. No. 5,715,413 (DRAGGING AND DROPPING WITH AN INSTANTIATION OBJECT) to Ishai et al (“Ishai”).
With regard to claims 1, 4, 21, 24, and 29, Lyon discloses the claimed computing system comprising:
a storage configured to store quantity values of a physical inventory of at least one item stored in a plurality of storage locations (see e.g. [0019-22]; [0013] involving data stores, relating to physical warehouse floors and physical items on the physical floor, see Lyon Fig. 2, showing the physical items on the physical cart in the physical warehouse); and
a processor (see e.g. [0020-22]) configured to
display a user interface that comprises a plurality of graphical user interface (GUI) elements therein corresponding to the plurality of storage locations, respectively (see e.g. [0020-22] user interface devices & GUI screens directing picker to a location and displaying pick quantities),
determine to perform a transfer operation of the at least one item from a first storage location corresponding to the first GUI element to a second storage location corresponding to the second GUI element (e.g. [0019-22] supplies the inventory context where movements/operations correspond to moving stock from location/bin to another during picking flows.The UI shows a source location and quantity, and the worker’s confirmation results in system operations reflecting movement to the destination bin/order (i.e. trans among storage locations)),
receive a quantity value via the user interface (see e.g. [0019] [0021-22]; [0051] verify pick quantity), and
modify data records stored within a database based on the determined transfer operation and the quantity value from the first storage location to the second storage location (Lyon discloses returning pertinent changes to a host or middleware system, and emphasizes that the solution performs calculations and data changes and connects to data stores, i.e., updating database records as a result of a user’s UI interactions. [0020] – return that data with pertinent changes to a host or middleware system; [0029] perform data changes at a device level; [0013] systems with data stores; [0031] Fig. 7).
Lyon does not disclose the following:
detect, via the user interface, movement of a first GUI element towards a second GUI (drag and drop of claims 4 and 24) element based on inputs received on the user interface,
However, Kim teaches at e.g. [0003] [0005] [0064] that it would have been obvious to one of ordinary skill in the GUI art to include the ability to drag and drop icons into various desired locations. For the detect limitation, see Kim at e.g. [0003] and [0005] and [0064]. See
[0003] A method, computer program product, and/or computer system controls icon movement behavior on a graphical user interface. A file hosting icon and a data file icon are displayed on a graphical user interface (GUI). The file hosting icon represents a file hosting service, and the data file icon, which is capable of being moved towards the file hosting icon on the GUI to initiate storage by the file hosting service, represents data. The behavior of movement of the data file icon is adjusted according to a position of the data file icon relative to a position of the file hosting icon on the GUI, and based on predefined features of the data relative to predefined features of the file hosting service.
[0005] FIG. 2 illustrates movement of a data icon towards a file hosting icon across an exemplary Graphical User Interface (GUI) in accordance with one or more embodiments of the present invention;
[0064] . . . [O]ne or more processors detect that the file hosting icon and/or the data file icon is being dragged towards a sensitivity icon (e.g., sensitivity icon 302 in FIG. 3). In response to detecting that the file hosting icon and/or data file icon has been dragged and dropped onto the sensitivity icon, one or more processors present sensitivity options to a user (e.g., via the sensitivity selection window 304 shown in FIG. 3). . . .
Therefore, it would have been obvious to one of ordinary skill in the inventory management art before the effective filing date of the claimed invention to modify where warehouse management system of Lyon to include such drag and drop detection capability, as shown in Kim, where this is beneficial so that the data of the first file can be stored with the contents of the second object/file. See e.g. Kim [0036]. Using Kim’s intuitive drag gesture in Lyon’s inventory UI to capture a location-to-location transfer and then commit the change to Lyon data store when an entered quantity would have been a predictable substitution to improve usability (KSR) by reducing manual form entries.
Lyon and Kim do not teach where responsive the determination to drag and drop, present a display window/input window/popup/prompt in a UI to request a user input value(s) corresponding to the transfer operation, and where the saving of the transfer is based on the parameters input by the user when prompted by the input window.
Ishai teaches at the following portions that it would have been obvious to one of ordinary skill in the drag-and-drop art to include the ability to display an input box where numbers can be input, that relate to the transfer operation, and then the input parameters can be saved along with the other data object(s) to be stored. Ishai does not discuss inventory management, but Lyon and Kim both discuss inventory management. Lyon discusses warehouse management system where a picker can be instructed to pick/move items in a warehouse, and the UI can present the amount to pick at a given location, and then have the user verify the number that were moved, where the verifying is done on a tablet, for instance. Kim discusses where a user can virtually move one item from one location to another location, in a database, by dragging and dropping an icon on the UI from one location to another location. Ishai teaches that upon the dragging and dropping operation, the input box can be displayed which prompts the user for more parameters relating to the drag and drop operation, such as by inputting integers, real numbers, that are input by the user, and then stored in association with the operation.
Ishai at:
Abstract - A graphical user interface (GUI) application program implemented in an object oriented programming language permits a user to instantiate new program objects by dragging an instantiation object from one GUI window to a new GUI window and dropping the instantiation object in the new window. When the instantiation object is dropped into the new window, an object specified by the new window type is automatically instantiated. If needed, the user is automatically prompted to provide parameters needed for the object instantiation according to the window in which the object is dropped.
Col. 3, ln. 40-50
Col. 10, ln. 40-60, For example, a variety of graphical, integer, real number, display, or other types of data can be represented, including an "undefined" data type category indicated by "u" in FIG. 11.
PNG
media_image1.png
624
300
media_image1.png
Greyscale
Col. 12, ln 49 – col. 13, ln. 20 - More particularly, a user highlights a data type component from the Components list, drags the highlighted component to the Record Format box, and drops it there. Each time a data type component is dragged from the Components box to the Record Format box, an Input Field Information panel like that illustrated in FIG. 15 is displayed. The Input Field Information panel provides a means for the user to specify a name and length for the field range being defined. Thus, the Input Field Information panel includes a Name field and a Length field in which the user provides the desired parameter information.
Fig. 26 - 2610, 2612 and col. 21, ln. 32-57 - In accordance with the parameters for instantiating an object, the data arranger program next displays whatever input panels are needed to receive the parameters from the user to complete the object definition. This processing step is represented in FIG. 26 by the flow diagram box numbered 2610. Next, the data arranger program saves the parameters and other data structures needed for the instantiated object, as indicated by the flow diagram box numbered 2612. This concludes processing for a drag-and-drop action with the Creator Object.
For the limitations relating to allowing the user to drag and drop an object from one location to another location, and to then prompt the user for more parameters for the drag and drop operation, the parameters including e.g. integers, real numbers, etc. and further where the operation is completed by saving the input parameters in association with the data structure(s) of the operation, the advantages and motivation to combine this into Lyon/Kim, are shown at Ishai col. 21, ln. 59 ADVANTAGES OF THE INVENTION, including As described above, the present invention provides a graphical user interface (GUI) application program implemented in an object oriented programming language that permits a user to automatically instantiate new program objects by dragging a Creator Object from one GUI window to a new GUI window and dropping it in the new window. If needed, the user is automatically prompted to provide parameters needed for the object instantiation according to the window in which the object is dropped. This provides an easier way for a user to specify a program operation and the data or resources involved in the operation.
Therefore, it would have been obvious to one of ordinary skill in the database management art to include the ability to drag-and-drop, then prompt for more parameter(s) relating to the drop, as shown in Ishai, where the advantages of such combination with Lyon/Kim, is that it provides an easier way for a user to specify a program operation and the data or resources involved in the operation. See Ishai, col. 21, ln. 59-67.
For the added limitation at the end of the claim relating to “wherein in response to generating the one or more database transactions, a first amount of the at least one item for the first storage location is reduced by the quantity value, and a second amount of the at least one item for the second storage location is increased by the quantity value.” The examiner refers to Lyon, e.g. [0002-3], where a picker in a warehouse is given an input order to go and move item1 from location1 to bin2 (Lyon [0003] “After an item has been picked, the picker can place the item in a desired bin, which may be used, for example, to keep separate orders organized, to keep similar items together, and so forth.” It is taught by Lyon, but it is also inherent, that when an item is picked from location1 and added to bin2, the inventory of location1 decreased by the amount taken, and bin2 increases by the amount added. When combined with Ishai, the computer inputs are merely commands that tell the picker what to do. For instance, in ishai, the system received an order for 5 of item2, the user indicates that 5 of item2 be moved from location1 to bin2, and then the pickers of Lyon see that input, and make sure the action is performed (i.e. decrease the inventory at location1 by 5, increase inventory at bin2 by 5). See combination above.
With regard to claims 2, 22, and 30, as shown above, Lyon/Kim/Ishai teach transfer UI to implement a quantity prompt. Lyon does not teach bringing the dragged object within a radius of the second element. However, Kim teaches at e.g. [0049-61] [0063-64] that it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lyon by having fences, or regions and fields around a target icon (i.e. second element as claimed) that trigger UI behaviors when the moving icon enters a region (i.e. predetermined radius of as claimed), and opening an options window upon entry see Kim at [0049-61] approach fields, and [0063-64] options/sensitivity window displayed. Applying Kim’s proximity trigger to Lyon’s transfer UI to pop up a quantity prompt when the source icon is within a predetermined area around the destination icon would have been a routine adaptation, and further the benefit is that this allows for more data aggregation while the drag and dropping as the movement triggers a window opening where more data can be added to the system, such as quantity, for instance.
With regard to claims 3 and 23, Lyon does not disclose the limitations of claims 3 and 23. However, Kim teaches at e.g. [0063-64] and [0039-42] that it would have been obvious to one of ordinary skill in the art before the effective filing date to include the ability to change the appearance from identical to each other, to different appearance, when the first element is selected, a shown in Kim, and applying this to Lyon’s system is an obvious design choice. In addition, this adds the benefit of being able to indicate data to the user, such as if the system determines that the modification of first icon is “inadvisable” then the color can change when movement is detected, thereby communicated to the user that the system does not recommend such movement.
With regard to claims 5, 25, and 31, Lyon is silent regarding the limitations 5, 25, and 31. Kim teaches these limitations at [0060-61] adjusting the behavior of the movement of the data file icon on the GUI results in a drag rate change in the movement of the data file icon. That is, the rate/speed at which an icon moves relative to movement of the mouse changes based on the relationship between the data represented by the data file icon relative to features of the file hosting service represented by the file hosting icon.
Claim(s) 6, 26, and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Lyon, Kim, Ishai, and U.S. Pat. Pub. No. 2024/0165673 to Zsigmond et al. (“Zsigmond”).
With regard to claims 6, 26, and 32, Lyon/Kim does not teach the limitations of claims 6, 26, and 32. Zsigmond teaches this at e.g. [0025, 27, 30-31, 47-49, 56-57] that it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Lyon/Kim to include a “scan button” that when pressed, causes scanning/reading of item identifiers/quantities and interaction with local/remote databases, where this is beneficial in that the scanning can be performed on demand, or in scheduled continuous intervals as outlined in Zsigmond in the portions referred to.
Claim(s) 7, 8 and 27, 28 are rejected under 35 U.S.C. 103 as being unpatentable over Lyon, Kim, Ishai, and U.S. Pat. Pub. No. 2003/0167213 to Jammes (“Jammes”).
With regard to claims 7 and 27, Lyon does not teach these limitations. Kim teaches options windows appearing in response to the proximity interaction (Kim [0063-64]. James teaches dialog boxes/pop-ups with editable fields and an OK action that stores entered values to the database. See Jammes e.g. [0292, 332]. Therefore, it would have been obvious to one of ordinary skill in the GUI art to include the claimed pop-up window with input field to update database, as taught by Jammes, with Lyon/Kim combination, as combining Kim’s proximity-prompt with Jammes’ standard modal input dialog box, as combined above, create the benefit that the UI can capture the transfer quantity, or any other value, at the moment the user commits to a transfer.
With regard to claims 8 and 28, Lyon further discloses host/middleware with a persistent data store 715 to maintain warehouse data and reflects user-driven updates ([0018-20], [0073-75]). Lyon does not mention the use of API of a database. Jammes teaches at e.g. ([0058-59] [0075] [0247-251], [0254]) that it would have been obvious to one of ordinary skill in the art to use an API of a database to execute commands, where Jammes explicitly teaches forming and sending database commands via server interfaces (an API) to update records in the database, where this is beneficial in that it allows the server to communicate with the database and modify/update/change various records.
Response to Arguments
Applicant's arguments filed 02/13/2026 have been fully considered but they are not persuasive.
Applicant argues that the amendment(s) are not taught by the cited references. The examiner respectfully disagrees. The examiner has referred to the combination of the references (e.g. Ishai shows the input, and Lyon shows the action of moving inventory from one spot to another). The examiner notes that the act of moving an inventory item from one spot to another spot, inherently decreases the inventory from the first spot and increases the inventory at the second spot, based on the amount taken, which is based on the input/command received by the picker, etc.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Peter Ludwig whose telephone number is (571)270-5599. The examiner can normally be reached Mon-Fri 9-5.
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, Fahd Obeid can be reached at 571-270-3324. 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.
/PETER LUDWIG/Primary Examiner, Art Unit 3627
Prosecution Insights