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 .
Formal Matters
Applicant’s response, filed 01/26/2026, has been fully considered. The following rejections and/or objections are either reiterated or newly applied. They constitute the complete set presently being applied to the instant application.
Status of Claims
Claims 1-15 are currently pending and have been examined.
Claims 1-2, 6, 9, and 11 have been amended.
Claims 1-15 have been rejected.
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-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claimed invention is directed to an abstract idea without significantly more. Claims 1-15 are directed to a system, method, or product which are one of the statutory categories of invention. (Step 1: YES).
Independent Claim 1 discloses an inventory management system comprising: a web-based inventory management software application having an application page comprising an input field for receiving data manually entered by a user; a user computing device configured with instructions to implement said software application and receive said data at a user interface of said application; a barcode reader and an RFID reader configured to scan a plurality of items in a kit, cart, or both; a server in communication with said barcode and RFID readers, said application page comprising said input field, said user computing device, and a database, said server comprising hardware configured to: receive from said barcode reader first item information associated with a first item, said first item information comprising at least one selected from the group of identification information, expiration information, and lot number information; automatically receive from said RFID reader second item information associated with a second item, said second item information comprising at least one selected from the group of identification information, expiration information, and lot number information; receive from said application page comprising said input field third item information comprising information about one or more untagged items; store the first, second, and third item information together at the database; associate each of said first, second, and third item information with an inventory cart, and communicate a cart type, for said inventory cart to said user interface; update said user interface [output] based on said first, second, and third item information; reject input provided below a speed threshold; and wherein said software application is configured to provide at said user interface real time inventory of said inventory cart.
Independent Claim 9 discloses an inventory management system comprising: a web-based inventory management software application having an application page comprising an input field for receiving data manually entered by a user; a user computing device, configured with instructions to implement said software application and receive said data at a user interface of said software application; a kit; an RFID reader and barcode reader in communication with said user computing device, said RFID reader and barcode reader configured to scan items in said kit; a server in communication with said user computing device, said application page comprising said input field, said RFID reader, said barcode reader and a database, said server comprising hardware configured to: receive kit instructions, said kit instructions comprising required items that must be present in to complete said kit; communicate cart type, earliest cart item expiration date, or both for an inventory cart having at least one kit included therewith to said user computing device; automatically receive from said RFID reader item information for a plurality of items detected in a scan performed by said RFID reader, wherein said item information for each of said plurality of items comprises at least one selected from the group of unique identification information, expiration information, and lot number information; compare said received item information with said kit instructions to identify whether all required items were present during said scan; calculate at least one selected from the group of whether any of said required items were missing, had expired, and had been recalled; update said user interface [output] based on information communicated to said server from said RFID reader, barcode reader, and application page comprising said input field; reject input data provided below a speed threshold; and wherein said software application is configured to provide at said user interface a real time inventory of said inventory cart
Independent Claim 11 discloses an inventory management system comprising: a web-based inventory management software application having an application page comprising an input field for receiving data manually entered by a user; a user computing device, configured with instructions to implement said software application and receive said data at a user interface of said software application; a container, configured to store one or more items; a barcode reading device and RFID reading device each positioned proximate to said container, and configured to scan a plurality of items in said container; a server in communication with said barcode and RFID reading devices, said application page comprising said input field, and a database; wherein said server is configured to receive, from the barcode and RFID reading devices, information about cart type, earliest cart item expiration date, or both for an inventory cart having at least one container included therewith, receive from said application page comprising said input field information about one or more untagged items, and reject input data provided below a speed threshold; wherein said server is configured to, based on information communicated to the server from the application page comprising said input field and the RFID and barcode reading devices, communicate to said user interface a notification that identifies items in said container that require addition, removal, or both; and wherein said software application is configured to provide at the user interface a real time inventory of said inventory cart.
The examiner is interpreting the above bolded limitations as additional elements as further discussed below. The remaining limitations are merely directed to directing a person on what to do based on notifications, like removing expired or recalled inventory and restocking a location. The series of steps recited above describe managing personal behavior or relationships or interactions between people and thus are grouped as certain methods of organizing human activity which is an abstract idea. (Step 2A- Prong 1: YES. The claims are abstract).
This judicial exception is not integrated into a practical application. Limitations that are not indicative of integration into a practical application include: (1) 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 (MPEP 2106.05.f), (2) Adding insignificant extra- solution activity to the judicial exception (MPEP 2106.05.g), (3) Generally linking the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05.h).
Independent Claim 1 discloses the following additional elements:
a web-based inventory management software application having an application page comprising an input field for receiving data manually entered by a user
a user computing device configured with instructions to implement said software application
a user interface
a barcode reader
a RFID reader
a server in communication with said barcode reader and RFID readers, said application page comprising said input field, said user computing device, and a database, said server comprising hardware
automatically receive from said RFID reader second item information associated with a second item
Independent Claim 9 discloses the following additional elements:
a web-based inventory management software application having an application page comprising an input field for receiving data entered by a user
a user computing device configured with instructions to implement said software application
a user interface
a RFID reader
a barcode reader
a server in communication with said user computing device, said application page comprising said input field, said RFID reader, said barcode reader and a database, and said server comprising hardware
automatically receive from said RFID reader item information for a plurality of items detected in a scan performed by said RFID reader
Independent Claim 11 discloses the following additional elements:
a web-based inventory management software application having an application page comprising an input field for receiving data manually entered by a user
a user computing device configured with instructions to implement said software application
a user interface
a barcode reading device
a RFID reading device
a server in communication with said barcode and RFID reading devices, said application page comprising said input field, and a database
The web-based inventory management software application having an application page comprising an input field for receiving data entered by a user (of claims 1, 9, and 11), user computing device configured with instructions to implement said software application (of claims 1, 9 and 11), user interface (of claims 1, 9, and 11), barcode reader (of claims 1 and 9), RFID reader (of claims 1 and 9), barcode and RFID reading device (of claim 11), a server in communication with said barcode reader and RFID readers, said application page comprising said input field, said user computing device, and a database, said server comprising hardware (of claims 1 and 9), the server in communication with said barcode and RFID reading devices, said application page comprising said input field, and a database (of claims 11), automatically receiving information from an RFID reader (claims 1 and 9) are recited at a high-level of generality such that it amounts to no more than mere instructions to implement an abstract idea by adding the words ‘apply it’ (or an equivalent) with the judicial exception.
Applicant’s specification at Paragraph 47 generally states, “The web application allows a plurality of users to view a wide variety of information and perform activities including, but not limited to, inputting information, generating reports, and running queries... Exemplary user devices include but are not limited to desktop computers, laptops, tablet computers, smart phones, and any other form of portable electronic device that is able to communicate with a web server over a network.” Accordingly, the user computing device is broadly disclosed, with no particularity, and is performing a routine function in an expected manner. Further, the user interface is broadly disclosed as a way of displaying the analysis of the abstract idea. The barcode reader, RFID reader automatically receiving information, database, and the server are all disclosed at a high level of generality, with no particularity. Each additional element is performing a routine function (scanning bar codes and RFID tags, receiving data, transmitting data, to paraphrase, for example) in an expected manner.
These additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Accordingly, claim(s) 1, 9, and 11 are directed to an abstract idea(s) without a practical application. (Step 2A-Prong 2: NO: the additional claimed elements are not integrated into a practical application).
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of the web-based inventory management software application having an application page comprising an input field for receiving data entered by a user (of claims 1, 9, and 11), user computing device configured with instructions to implement said software application (of claims 1, 9 and 11), user interface (of claims 1, 9, and 11), barcode reader (of claims 1 and 9), RFID reader (of claims 1 and 9), barcode and RFID reading device (of claim 11), a server in communication with said barcode reader and RFID readers, said application page comprising said input field, said user computing device, and a database, said server comprising hardware (of claims 1 and 9), the server in communication with said barcode and RFID reading devices, said application page comprising said input field, and a database (of claims 11), and automatically receiving information from an RFID reader (claims 1 and 9) amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept ("significantly more' ). MPEP2106.05(I)(A) indicates that merely saying "apply it” or equivalent to the abstract idea cannot provide an inventive concept ("significantly more").
Accordingly, even in combination, this additional element does not provide significantly more. As such the independent claims 1, 9, and 11 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more).
Dependent Claims 2-8, 10, and 12-15 further define the abstract idea that is presented in the respective Independent 1, 9, and 11 and are further grouped as certain methods of organizing human activity and are abstract for the same reasons and basis as presented above.
Dependent claim(s) 2-8 further narrow the abstract idea presented in independent
claim 1 and/or claims it depends on with no recitation of any further additional elements.
Dependent claim(s) 10 further narrows the abstract idea presented in independent
claim 9 and/or claims it depends on with no recitation of any further additional elements.
Dependent claim(s) 12 further narrows the abstract idea presented in independent claim 11 and/or claims it depends on while further disclosing the additional elements of a RFID tag (Claim 12).
Dependent claim(s) 13-15 further narrow the abstract idea presented in independent
claim 11 and/or claims it depends on with no recitation of any further additional elements.
The RFID tag is recited at a high-level of generality such that it amounts to no more than mere instructions to implement an abstract idea by adding the words ‘apply it' (or an equivalent) with the judicial exception. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of the RFID tag amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept ("significantly more' ). MPEP2106.05(I)(A) indicates that merely saying "apply it” or equivalent to the abstract idea cannot provide an inventive concept ("significantly more"). Accordingly, this additional element does not provide significantly more.
Therefore, the dependent claims are also directed to an abstract idea.
Thus, Claims 1-15 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Caputo (US PG Pub 2014/0291397 A1), in view of MacDonald (US PG Pub 2021/0383323 A1) further in view of the Stack Overflow reference (How to make a field only editable by scanning in a bar code as values?).
Regarding Claim 1, Caputo discloses:
An inventory management system comprising: (Para 30 discloses those skilled in the art have recognized a need for an improved real-time inventory system for managing medical article container systems. Additionally, a need has been recognized for performing such article management with a more compact, self-contained wireless reader system that reduces the space needed to inventory crash carts and trays.)
a user computing device; configured with instructions to implement said software application and receive said data at a user interface of said software application (Para 133 discloses In this case, the computer comprises a processor 424, a display 426, and an input device 428 which in this case is a keyboard. Para 150 discloses a user may instruct the inventory management system 410 through an input device 428, to register the container under a certain category, including specialized and/or individualized categories. Para 153 discloses processor includes hardware for executing instructions, such as those making up software. Herein, reference to software may encompass one or more applications, byte code, one or more computer programs, one or more executable, one or more instructions, logic, machine code, one or more scripts, or source code, and vice versa, where appropriate. Para 156 discloses input/output (I/O) interface, includes hardware, software, or both for providing one or more interfaces for communication between computer system and one or more I/O devices.)
an RFID reader configured to scan a plurality of items in a kit, cart, or both; automatically receive from said RFID reader second item information associated with a second item, said second item information comprising at least one selected from the group of identification information, expiration information, and lot number information (Para 38 and Fig. 3 disclose a block and flow diagram showing an embodiment in which an RFID reader transmits activating EM energy into a drawer containing RFID tags with a single transmitting antenna, receives the data output from the activated RFID tags with a single receiving antenna, a computer controlling the transmission of activating energy and receiving the data from the activated RFID tags for processing; Para 131 discloses it should be noted that use of a Faraday cage is highly beneficial in healthcare facilities due to the ubiquitous presence of medical articles that have RFID tags. Without the ability to electrically isolate the tray or crash cart to be read, an RFID reader may read the RFID tags of other pharmaceuticals on shelves outside the tray or crash cart thereby giving the operator the incorrect information that those external read articles are in the tray or crash cart [kit or cart]. Para 133 discloses an RFID reader 430 obtains the RFID tag's serial number and assigns it to the medication information in the medication to which the RFID tag is mounted. In this case, the information about the medication comprises: the drug name, the dose, the volume, the expiration date, the manufacturer's name, the lot number, the NDC number, the UPC number, the tray number in which the medication will be store, and the location of the medication in the tray. Para 135 discloses while the embodiment herein described refer to "trays," other container types may function equally well. It is not meant to confine the invention to any particular type of container unless so indicated.)
a server in communication with said RFID readers, said application page comprising said input field, said user computing device, and a database, said server comprising hardware configured to: (Para 124 discloses as in the local computer, these remote databases may be stored on a memory that is internal to the server or that is external to the server. Further, the server 360 may be located nearby the local computer 346 or may be remote therefrom. Para 125 discloses the remote database 362 at the server 360 may serve as a main database and contain data for all medical articles, medical containers, and other inventory for all medical locations/facilities/specialties. Para 133 discloses a medication vial 412 on which an RFID tag 414 is mounted is being registered with the system 410 by entering the RFID tag's serial number 416 along with the relevant information 418 about the medication in the vial 412 into an "articles database" 420 by the computer 422. In this case, the computer comprises a processor 424, a display 426, and an input device 428 which in this case is a keyboard. Para 150 discloses a user may instruct the inventory management system 410 through an input device 428, to register the container under a certain category [broadest reasonable interpretation of an application page comprising input field to register the container], including specialized and/or individualized categories.)
store the first, second, and third item information together at the database; (Para 125 discloses the remote database 362 at the server 360 may serve as a main database and contain data for all medical articles, medical containers, and other inventory for all medical locations/facilities/ specialties. Para 133 discloses an RFID reader 430 obtains the RFID tag's serial number and assigns it to the medication information in the medication to which the RFID tag is mounted. In this case, the information about the medication comprises: the drug name, the dose, the volume, the expiration date, the manufacturer's name, the lot number, the NDC number, the UPC number, the tray number in which the medication will be stored, and the location of the medication in the tray. Para 135 discloses while the embodiment herein described refer to "trays," other container types may function equally well. It is not meant to confine the invention to any particular type of container unless so indicated.)
associate each of said first (Para 62 and Fig. 27 disclose a perspective view of a much larger enclosure for crash carts that also provides an electromagnetic field within to activate, detect, and read all RFID tags in the crash cart and provide their identifications. Para 131 discloses it should be noted that use of a Faraday cage is highly beneficial in healthcare facilities due to the ubiquitous presence of medical articles that have RFID tags. Without the ability to electrically isolate the tray or crash cart to be read, an RFID reader may read the RFID tags of other pharmaceuticals on shelves outside the tray or crash cart thereby giving the operator the incorrect information that those external read articles are in the tray or crash cart. Para 142 and Fig. 32 disclose a computer program screen shot 540 of a listing of the articles detected in a tray during a scan of that tray in accordance with aspects of the invention. Various categories are shown including expiration 542 and recall 544. Incorrect articles 546 may be listed and for convenience, the entire Required Inventory list can be displayed as well as a check mark next to each one that is present and not expired. Many different forms of the display of results from scanning a tray, crash cart, or other container may be provided. FIG. 32 is just one embodiment.
communicate a cart type, for said inventory cart to said user interface[[,]]; (Paras 26-27 disclose a need has been identified to provide a more efficient and accurate system and method to restock such carts and trays. Crash carts and trays must be resupplied periodically to replace expired or recalled items, and if a cart or a tray was actually used, to replace consumed articles. Para 58 and Fig. 23 discloses the crash cart may be supplied to support a particular use in a healthcare facility, such as the intensive care unit, pediatrics, or other [thus indicating that the carts have types]. Para 134 discloses in the tray database, the tray RFID tag identification is connected with the type and name of the tray and the RFID tag numbers are connected with the medical articles placed in the tray. Trays may have certain categories, such as ER, or ICU, or pediatric, or other, and the tray database will indicate that category for the RFID no. of the tray RFID tag. Para 135 discloses while the embodiment herein described refer to "trays," other container types may function equally well. It is not meant to confine the invention to any particular type of container unless so indicated. Wherein para 142 discloses “a tray, crash cart, or other container” thus indicating that a crash cart is considered another container type. Thus is would have been obvious to implement the a “cart database” that stores the cart RFID tag identification connected with the type and name of the cart.)
update said user interface based on said first, second, and third item information; and wherein said software application is configured to provide at said user interface real time inventory of said inventory cart. (Para 142 and Fig. 32 disclose a computer program screen shot 540 of a listing of the articles detected in a tray during a scan of that tray in accordance with aspects of the invention. Various categories are shown including expiration 542 and recall 544. Incorrect articles 546 may be listed and for convenience, the entire Required Inventory list can be displayed as well as a check mark next to each one that is present and not expired. Many different forms of the display of results from scanning a tray, crash cart, or other container may be provided. FIG. 32 is just one embodiment.)
While Caputo discloses the above limitations and “a computer program screen shot 540 of a listing of the articles detected in a tray during a scan of that tray in accordance with aspects of the invention” (Para 142 and Fig. 32) and, “ a user may instruct the inventory management system 410 through an input device 428 [broadest reasonable interpretation of an application page comprising input field to register the container], to register the container [untagged items] under a certain category,” (Para 150), it does not fully disclose the following limitations that MacDonald discloses:
a web-based inventory management software application having an application page comprising an input field for receiving data manually entered by a user; receive from said application page comprising said input field third item information comprising information about one or more untagged items; (Para 56 discloses a user interface and one or more software applications allowing a user to access information regarding the status of kits. Para 125-126 discloses computer 405 comprises a browser 410 that receives kit information from the RFID reader via LAN 435 and communicates with server 420 through the internet 415. Para 137 discloses system 100 may scan the items and look up item information from the third party or an additional third party. Such information may include, for example, item master data, item lot data, and item expiration dates. If the items are not already tagged, item information may be entered into system 100 using a bar code scanner as described above, or by manual user input (610) [wherein the ability to manually input data reads on the broadest reasonable interpretation of an application page comprising an input field]. See Further: Paras 144-145.)
Wherein the Applicant’s specification does not distinguish the difference between a kit and a tray, and Caputo discloses in para 142, “many different forms of the display of results from scanning a tray, crash cart, or other container may be provided.” Thus, although Caputo does not specifically disclose the internet, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the computer program of Caputo (Caputo Para 142) with the software application, RFID readers, and communication with the server through the internet (MacDonald Para 56 and 125-126).
While Caputo discloses, “there are a number of ways of identifying and tracking articles including visually, optically (bar coding, for example)…RFID… and others” (Para 3), MacDonald further discloses:
a barcode reader configured to scan a plurality of items in a kit, cart, or both; a server in communication with said barcode reader, receive from said barcode reader first item information associated with a first item, said first item information comprising at least one selected from the group of identification information, expiration information, and lot number information; (Para 46 discloses items may arrive at a hospital pre-tagged. One way to tag the items is by scanning bar codes present on most items used in a kit, printing RFID tags based on the scanned bar codes, and then applying the RFID tags to the items. The scanned bar codes typically provide item information such as product identifiers (e.g., NDC or UPC), lot numbers, and expiration dates. This information can be associated with the RFID tags in a computer database to allow subsequent identification and processing by RFID technology. Para 53 discloses the automatic processing provided by RFID technology and associated electronic equipment allows kit management to be performed with greater efficiency and accuracy compared with conventional approaches. For instance, in some embodiments, kit contents and expiration dates can be validated in 15 seconds or less. Para 125-126 discloses referring to FIG. 13, information processing system 115 comprises a computer 405 and a server 420. Computer 405 and server 420 are connected to each other via the internet 415, and computer 405 is connected to an RFID reader, a bar code reader, and an RFID printer through a local area network (LAN) 435.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the real-time inventory re-supply system as taught by Caputo with the barcode reader as taught by MacDonald in order to tag the items by scanning bar codes present on most items used in a kit, printing RFID tags based on the scanned bar codes, and then applying the RFID tags to the items in order to allow subsequent identification and processing by RFID technology (MacDonald Para 46).
While the combination of Caputo and MacDonald discloses the above limitations, it does not fully disclose the following limitation that the Stack Overflow reference discloses:
reject input data provided below a speed threshold; (User “testItAll” asked how to implement a system that only allows a user to “edit” through a scan gun to capture a bar code as they wish to prevent the user from adding data via keyboard while still allowing data to be entered via scan. User “Joshua Leonard” answered the question with, “Usually barcode scanners act as a keyboard input, which would prevent you from knowing whether it’s a keyboard or a scanner. One way to get around this is to check the timing between keypresses. The barcode scanner inputs much faster than a human, and I believe you can modify this speed. If the typing is slow enough [below a speed threshold so you reject it] you'll know it’s a keyboard. If the typing is within some threshold [above a speed threshold so you don’t reject it] you will know it’s the scanner.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of the real-time inventory re-supply system as taught by Caputo and the barcode reader as taught by MacDonald with a threshold as taught by the Stack Overflow reference in order to limit data to that of a scanner instead of a keyboard to increase speed of data collection as well as eliminate human error.
Regarding Claim 7, this claim recites the limitations of Claim 1 and as to those limitations is
rejected for the same basis and reasons as disclosed above. The combination of Caputo, MacDonald, and the Stack Overflow reference further discloses the following limitation that MacDonald discloses:
The inventory management system of Claim 1, wherein said server is further configured to: calculate the expiration status of at least one kit; and cause a user device to display said expiration status of said at least one kit. (Para 45 discloses a kit management system uses RFID technology to label and track the contents of a kit. The use of RFID technology can allow a pharmacy to accurately and efficiently determine whether items in the kit are consumed, missing, expired, or near expiration [expiration status of a kit]. These determinations can be used thereafter to verify and update the kit contents, track item usage patterns, generate patient billing information based on item consumption, and so on. Para 53 discloses kit contents and expiration dates can be validated in 15 seconds or less. Moreover, kit deficiencies can be reported to a pharmacist automatically, allowing them to be addressed in an efficient manner. This reporting can be accomplished, for instance, by an automatically generated charge sheet showing kit contents and expirations. Para 56 discloses the kit management system typically further comprises a user interface and one or more software applications allowing a user to access information regarding the status of kits. As an example, a software application may be used to generate and print a kit charge sheet or charge sheet with the contents and expiration dates of the items and a kit.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Caputo and the Stack Overflow reference by substituting the trays of the real-time inventory re-supply system as taught by Caputo with the kits of the management of pharmacy kits using multiple acceptance criteria for pharmacy kit segments as taught by MacDonald as the Applicant’s specification does not specify a difference between the kits and trays, and the broadest reasonable interpretation of the limitation of a kit is that a tray could be considered a kit of medical items.
Claim(s) 2-5 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Caputo (US PG Pub 2014/0291397 A1), in view of MacDonald (US PG Pub 2021/0383323 A1), further in view of the Stack Overflow reference (How to make a field only editable by scanning in a bar code as values?) and Lunak (US PG Pub 2003/0105552 A1).
Regarding Claim 2, this claim recites the limitations of Claim 1 and as to those limitations is
rejected for the same basis and reasons as disclosed above. The combination of Caputo, MacDonald, and the Stack Overflow reference does not fully disclose the following limitation that Lunak discloses:
The inventory management system of Claim 1, wherein said server is further configured to: associate at least one of said first item, said second item, and said third item with a bin, wherein said bin is defined by at least one identification characteristic; (Para 42 discloses each of the bins carries indicia 44 which may be, for example, a barcode and/or a label identifying the contents of the bin. Additionally, items in the bins may have a bar code, label or other indicia directly on them or on their packaging. Para 44 discloses FIG. 5 illustrates a carousel 46 comprised of a plurality of bins 48 arranged in a plurality of rows 50… Each of the bins 48 carries indicia 55, which may be, for example, a barcode and/or a label indicating the contents of the bin, similar to indicia 44 in FIG. 4.)
store identification information for every item associated with said bin in said database; receive (Para 41 and FIG. 4 disclose another example of hardware which may be located at any of the decentralized storage locations 12-1 through 12-n… An optional interface computer 38 may be provided, which is in communication with the database. Para 42 discloses each of the bins carries indicia 44 which may be, for example, a barcode and/or a label identifying the contents of the bin [information about items present in bin]. Para 46 discloses the carousel 46 is under the control of a workstation 62, which may be comprised of a personal computer in communication with the database. The workstation 62 receives information from the database regarding items, and quantities for each item, needed to replenish each of the decentralized storage locations 12-1 through 12-n…)
provide a bin notification to a user based on the comparison. (Para 46 discloses the workstation 62 receives information from the database regarding items, and quantities for each item, needed to replenish each of the decentralized storage locations 12-1 through 12-n or to fulfill patient dispenses. The workstation 62 processes the information and presents to the user through a screen 64 a series of operations referred to as "picks". The information displayed on the screen may include, for example, an identification of the decentralized storage location, an identification of a cabinet, tower, shelving unit, etc. at the decentralized location, an identification of the patient, the item and quantity to be picked [bin notification based on the comparison].)
Caputo, MacDonald, and Lunak are all analogous art because each reference discloses methods for inventory management. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of the real-time inventory re-supply system as taught by Caputo, the management of pharmacy kits using multiple acceptance criteria for pharmacy kit segments as taught by MacDonald, and the threshold as taught by the Stack Overflow reference with the bins of the carousel product for use in integrated restocking and dispensing system as taught by Lunak in order to improve a restocking process and a carousel product that can be used for a wide variety of associated tasks, e.g. inventory control (Lunak Para 2).
Regarding Claim 3, this claim recites the limitations of Claim 2 and as to those limitations is
rejected for the same basis and reasons as disclosed above. While Lunak discloses a bin notification and, “the workstation 62 receives information from the database regarding items, and quantities for each item, needed to replenish each of the decentralized storage locations 12-1 through 12-n or to fulfill patient dispenses. The workstation 62 processes the information and presents to the user through a screen 64 a series of operations referred to as "picks." The information displayed on the screen may include, for example, an identification of the decentralized storage location, an identification of a cabinet, tower, shelving unit, etc. at the decentralized location, an identification of the patient, the item and quantity to be picked [bin notification],” (para 46), it does not fully disclose the specific notification that Caputo discloses:
The inventory management system of Claim 2, wherein said bin notification is at least one selected from the following group: notification of a missing item, notification of an item that does not have said at least one identification characteristic, and notification of a number of recognized items. (Para 147 discloses the inventory management system in accordance with the invention may display a list [notification] of every medical item missing from the medical container, any additional medical items not within the inventory list, any drugs with incorrect dosages, and any expiration date and/or status of every medical item within the container that is attached to a data carrier with identification data.)
Caputo, MacDonald, and Lunak are all analogous art because each reference discloses methods for inventory management. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Caputo, MacDonald, and the Stack Overflow reference by utilizing the displaying of missing items from a medical container of the real-time inventory re-supply system as taught by Caputo for the bins of the carousel product for use in integrated restocking and dispensing system as taught by Lunak wherein the bin is a substitute of the medical container as taught by Caputo.
Regarding Claim 4, this claim recites the limitations of Claim 2 and as to those limitations is
rejected for the same basis and reasons as disclosed above. The combination of Caputo, MacDonald, and the Stack Overflow reference does not fully disclose the following limitation that Lunak discloses:
The inventory management system of Claim 2, wherein said server is further configured to: receive from (Para 64 discloses the computer 90 receives information from the decentralized storage locations 12-1 through 12-n and provides information to the carousel work station 62 and/or the Robot-Rx support station 89 to enable restocking packages 96 to be prepared. Para 66 discloses where centralized storage location 10 is used to restock decentralized locations 12-1 through 12-n having Acidosis-Rx™ cabinets, the restocking process may be initiated in an automated manner. The ability to track inventory levels on the Acidosis-Rx™ cabinets enables the database computer 90 to indicate when par levels are low and will trigger a flag [par level notification] for the restock to occur, as opposed to restock happening at periodic times or other methods not based on actual levels. Para 75 discloses the carousel will implement two methods of restocking items that are low on inventory. One will be a static method, where the hospital configures a maximum and par level for each item in the carousel. Once the inventory falls below the par level, the item will be requested as a restock. Para 76 discloses the events and transactions generated from the carousel and other automated systems will be moved to a separate long-term storage system. This system will record the dispense, inventory count, restock, and configuration (assignment and de-assignment) actions taken against the carousel, including, but not limited to, the following information: date and time, station, user, medication, and quantity.)
Caputo, MacDonald, and Lunak are all analogous art because each reference discloses methods for inventory management. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of the real-time inventory re-supply system as taught by Caputo, the management of pharmacy kits using multiple acceptance criteria for pharmacy kit segments as taught by MacDonald, and the threshold as taught by the Stack Overflow reference with the bins of the carousel product for use in integrated restocking and dispensing system as taught by Lunak in order to improve a restocking process and a carousel product that can be used for a wide variety of associated tasks, e.g. inventory control (Lunak Para 2).
Regarding Claim 5, this claim recites the limitations of Claim 4 and as to those limitations is
rejected for the same basis and reasons as disclosed above. The combination of Caputo, MacDonald, and the Stack Overflow reference does not fully disclose the following limitation that Lunak discloses:
The inventory management system of Claim 4, wherein said par level notification is at least one selected from the following group: notification that the current number of items associated with said bin is less than the par level, and notification that the current number of items associated with said bin is within a certain number of items of the par level. (Para 64 discloses the computer 90 receives information from the decentralized storage locations 12-1 through 12-n and provides information to the carousel work station 62 and/or the Robot-Rx support station 89 to enable restocking packages 96 to be prepared. Para 66 discloses where centralized storage location 10 is used to restock decentralized locations 12-1 through 12-n having Acidosis-Rx™ cabinets, the restocking process may be initiated in an automated manner. The ability to track inventory levels on the Acidosis-Rx™ cabinets enables the database computer 90 to indicate when par levels are low and will trigger a flag [par level notification] for the restock to occur, as opposed to restock happening at periodic times or other methods not based on actual levels. Para 75 discloses the carousel will implement two methods of restocking items that are low on inventory. One will be a static method, where the hospital configures a maximum and par level for each item in the carousel. Once the inventory falls below the par level, the item will be requested as a restock [notification].)
Caputo, MacDonald, and Lunak are all analogous art because each reference discloses methods for inventory management. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of the real-time inventory re-supply system as taught by Caputo, the management of pharmacy kits using multiple acceptance criteria for pharmacy kit segments as taught by MacDonald, and the threshold as taught by the Stack Overflow reference with the bins of the carousel product for use in integrated restocking and dispensing system as taught by Lunak in order to improve a restocking process and a carousel product that can be used for a wide variety of associated tasks, e.g. inventory control (Lunak Para 2).
Regarding Claim 8, this claim recites the limitations of Claim 5 and as to those limitations is
rejected for the same basis and reasons as disclosed above. The combination of Caputo, MacDonald, the Stack Overflow reference and Lunak discloses the following limitation that Caputo further discloses:
The inventory management system of Claim 5, wherein said server is configured to: calculate the expiration status of at least one inventory cart; and cause a user device to display said expiration status of said at least one inventory cart. (Para 31 discloses a system and a method to manage the inventories of medical article storage containers, including trays and crash carts. Para 32 discloses the processor is also configured to determine if the article in the storage container is expired through locating the details of the medical article, including its expiration date, from the memory, comparing that expiration date to the present date, and providing a notice of expiration [calculating and displaying said expiration status of the storage container wherein a storage container could include a crash cart] if the two dates match or if the expiration date of the medical article preceded the present date. The memory includes a database in which the details of recalled items are contained, and the processor further being programmed to compare the details of the medical article in the storage container to the recalled article database on the memory, and if the comparison shows that the medical article is recalled, to provide an indication of such recall status.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Caputo (US PG Pub 2014/0291397 A1), in view of MacDonald (US PG Pub 2021/0383323 A1), further in view of the Stack Overflow reference (How to make a field only editable by scanning in a bar code as values?) and Shrivastava (US PG Pub 2020/0259237 A1).
Regarding Claim 6, this claim recites the limitations of Claim 1 and as to those limitations is
rejected for the same basis and reasons as disclosed above.
Caputo further discloses the following limitation:
The inventory management system of Claim 1, and… cart type of said inventory cart, (Paras 26-27 disclose a need has been identified to provide a more efficient and accurate system and method to restock such carts and trays. Crash carts and trays must be resupplied periodically to replace expired or recalled items, and if a cart or a tray was actually used, to replace consumed articles. Para 58 and Fig. 23 discloses the crash cart may be supplied to support a particular use in a healthcare facility, such as the intensive care unit, pediatrics, or other [thus indicating that the carts have types]. Para 134 discloses in the tray database, the tray RFID tag identification is connected with the type and name of the tray and the RFID tag numbers are connected with the medical articles placed in the tray. Trays may have certain categories, such as ER, or ICU, or pediatric, or other, and the tray database will indicate that category for the RFID no. of the tray RFID tag. Para 135 discloses while the embodiment herein described refer to "trays," other container types may function equally well. It is not meant to confine the invention to any particular type of container unless so indicated. Wherein para 142 discloses “a tray, crash cart, or other container” thus indicating that a crash cart is considered another container type. Thus, the “cart database” stores the cart RFID tag identification connected with the type and name of the cart.)
MacDonald discloses:
wherein said server is further configured to: store a location of a kit in said database; (Para 55-56 discloses the stored information can be inspected to determine the location of kits containing expired items. The kit management system can also comprise or be integrated with a real-time tracking system to maintain current information regarding kit locations. Para 155 discloses report 1100 still further comprises a portion 1135 indicating a current location of the kit and providing a “check out” button for assigning the kit to a specific location or person. In this example, the kit is currently assigned to the location “Central Pharmacy”.)
provide, in response to an inquiry received from a user device, the location of said kit; and (Para 55-56 discloses a user may simply request monitoring or a report as needed. As other examples, a software application may be used to generate inventory reports showing where kits are dispatched within a hospital, an expiration report indicating dispatched items that are expired or near expiration, consumption and usage reports with traceability to departments, code types, or patients. The kit management system can also comprise or be integrated with a real-time tracking system to maintain current information regarding kit locations. The real-time tracking system typically comprises electronic components associated with the kits and configured to transmit information from the kits to the information processing system to identify the kits' respective locations. Such tracking systems can also be combined with kit management software in order to update the information used to generate inventory reports.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of the real-time inventory re-supply system as taught by Caputo and the threshold as taught by the Stack Overflow reference with the management of pharmacy kits as taught by MacDonald in order to maintain current information regarding kit locations (MacDonald para 56).
Further, MacDonald discloses the following limitation:
and an expiration date of said kit.(Para 45 discloses a kit management system uses RFID technology to label and track the contents of a kit. The use of RFID technology can allow a pharmacy to accurately and efficiently determine whether items in the kit are consumed, missing, expired, or near expiration [expiration status of a kit]. These determinations can be used thereafter to verify and update the kit contents, track item usage patterns, generate patient billing information based on item consumption, and so on. Para 53 discloses kit contents and expiration dates can be validated in 15 seconds or less. Moreover, kit deficiencies can be reported to a pharmacist automatically, allowing them to be addressed in an efficient manner. This reporting can be accomplished, for instance, by an automatically generated charge sheet showing kit contents and expirations. Para 55-56 discloses a user may simply request monitoring or a report as needed. As other examples, a software application may be used to generate inventory reports showing where kits are dispatched within a hospital, an expiration report indicating dispatched items that are expired or near expiration, consumption and usage reports with traceability to departments, code types, or patients… the kit management system typically further comprises a user interface and one or more software applications allowing a user to access information regarding the status of kits. As an example, a software application may be used to generate and print a kit charge sheet or charge sheet with the contents and expiration dates of the items and a kit.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the trays of the real-time inventory re-supply system as taught by Caputo with the kits of the management of pharmacy kits using multiple acceptance criteria for pharmacy kit segments as taught by MacDonald as the Applicant’s specification does not specify a different between the kits and trays, and the broadest reasonable interpretation of the limitation of a kit is that a tray could be considered a kit of medical items.
While Caputo, MacDonald, and the Stack Overflow reference disclose the above limitations, the combination does not fully disclose the following limitations that Shrivastava discloses:
store a location of said inventory cart in said database; (Para 94 discloses the MC 308 also can collect status and sensor data and store it in the database 320. In some implementations the NCs 306 or the WCs 304 also can transmit status or sensor data directly to the database 320 for storage. Para 112 discloses the window control system is the window network and controllers. Para 270 discloses the location information may be stored and/or transmitted on a window network and/or an associated antenna network. In some embodiments, antenna and/or controller networks transmit location information to one or more ancillary systems including but not limited to… inventory systems, and safety systems. Para 276-277 discloses the location logic and associated user software may be enabled to allow a user to remotely keep track of where devices are located on a floorplan or map. In doing so it may be possible to log the movement of assets or users. Vertical movement, e.g., between floors or onto a mezzanine, can also be tracked. The location software may determine the location of the crash cart, or the nearest crash cart, to enable hospital staff to find the nearest cart and/or the nearest cart having the assets that they need in order to address the current emergency. Geo-fencing may also be implemented to improve inventory of consumable assets such as drugs. For example, location software may be configured to identify a drug (e.g., an emergency cardiac drug) as being consumed once it has been moved from its stored location, e.g. in a cabinet or a crash cart.)
provide, in response to an inquiry received from a user device, the location of said inventory cart, (Para 277 discloses software running on an administrative computer of the entity managing the assets on window network, and/or a mobile device that receives the location of assets within the hospital may be used by medical staff to quickly find the nearest asset that is requested allowing for expedited medical treatment. In some embodiments, the tagged assets may be mobile, e.g. on a crash cart or other movable/moving conveyance in a hospital (and/or the crash cart itself is tagged with a micro-location chip). The location software may determine the location of the crash cart, or the nearest crash cart, to enable hospital staff to find the nearest cart and/or the nearest cart having the assets that they need in order to address the current emergency.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of the real-time inventory re-supply system as taught by Caputo, the management of pharmacy kits as taught by MacDonald, and the threshold as taught by the Stack Overflow reference with the location software as taught by Shrivastava in order to determine the location of the crash cart, or the nearest crash cart, to enable hospital staff to find the nearest cart in order to address the current emergency (Shrivastava para 277) and further by substituting the carts having the assets that they need in order to address the current emergency with the specific cart types as taught by Caputo in order to track the location of specific cart types in order to address a current emergency.
Claim(s) 9-15 are rejected under 35 U.S.C. 103 as being unpatentable over MacDonald (US PG Pub 2021/0383323 A1), in view of Caputo (US PG Pub 2014/0291397 A1), further in view of the Stack Overflow reference (How to make a field only editable by scanning in a bar code as values?).
Regarding Claim 9, MacDonald discloses:
An inventory management system comprising:
a web-based inventory management software application having an application page comprising an input field for receiving data entered by a user; (Para 56 discloses a user interface and one or more software applications allowing a user to access information regarding the status of kits. Para 125-126 discloses computer 405 comprises a browser 410 that receives kit information from the RFID reader via LAN 435 and communicates with server 420 through the internet 415. Para 137 discloses if the items are not already tagged, item information may be entered into system 100 using a bar code scanner as described above, or by manual user input (610) [wherein the ability to manually input data reads on the broadest reasonable interpretation of an application page comprising an input field]. See Further: Paras 144-145.)
a user computing device, configured with instructions to implement said software application and receive said data at a user interface of said software application; (Para 56 discloses a user interface and one or more software applications allowing a user to access information regarding the status of kits [thus disclosing that the user interface is utilizing the software applications to access information].)
a kit (Para 8 discloses a method of managing a pharmacy kit using an electronic information processing system comprises defining, in the electronic information processing system, multiple rules for determining whether a segment of a pharmacy kit is satisfactorily stocked. Para 47 discloses a kit is typically built by placing tagged items in a container such as a box, tray, or canister, and optionally labeling the kit with an RFID tag having information such as a kit identifier, kit type, intended user, or location, for example.)
an RFID reader and barcode reader in communication with said user computing device, said RFID reader and barcode reader configured to scan items in said kit; a server in communication with said user computing device, said application page comprising said input field, said RFID reader, said barcode reader and a database, said server comprising hardware configured to: (Para 46 discloses one way to tag the items is by scanning bar codes present on most items used in a kit, printing RFID tags based on the scanned bar codes, and then applying the RFID tags to the items. The scanned bar codes typically provide item information such as product identifiers (e.g., NDC or UPC), lot numbers, and expiration dates. This information can be associated with the RFID tags in a computer database to allow subsequent identification and processing by RFID technology. In some embodiments, the RFID tags can be generated automatically when scanning the bar codes, e.g., through the use of an RFID tag printer operatively connected to a bar code scanning machine. Para 53 discloses the automatic processing provided by RFID technology and associated electronic equipment allows kit management to be performed with greater efficiency and accuracy compared with conventional approaches. For instance, in some embodiments, kit contents and expiration dates can be validated in 15 seconds or less. Para 125-126 discloses referring to FIG. 13, information processing system 115 comprises a computer 405 and a server 420. Computer 405 and server 420 are connected to each other via the internet 415, and computer 405 is connected to an RFID reader, a bar code reader, and an RFID printer through a local area network (LAN) 435. Para 137 discloses if the items are not already tagged, item information may be entered into system 100 using a bar code scanner as described above, or by manual user input (610) [wherein the ability to manually input data reads on the broadest reasonable interpretation of an application page comprising an input field].)
receive kit instructions, said kit instructions comprising required items that must be present in to complete said kit; (Para 8 discloses a method of managing a pharmacy kit using an electronic information processing system comprises defining, in the electronic information processing system, multiple rules for determining whether a segment of a pharmacy kit is satisfactorily stocked, selecting, by the electronic information processing system, at least one rule among the multiple rules according to a kit stocking contingency, and prompting, by the electronic information processing system, a user to stock the segment of the pharmacy kit according to the selected at least one rule. Para 68 discloses one of the most common ways of processing information captured from a kit is comparing the captured information with a template of the kit to determine whether the kit is satisfactorily stocked. The template of a kit defines items that are required to be placed in the kit.)
automatically receive from said RFID reader item information for a plurality of items detected in a scan performed by said RFID reader, wherein said item information for each of said plurality of items comprises at least one selected from the group of unique identification information, expiration information, and lot number information; (Para 53 discloses the automatic processing provided by RFID technology and associated electronic equipment allows kit management to be performed with greater efficiency and accuracy compared with conventional approaches. For instance, in some embodiments, kit contents and expiration dates can be validated in 15 seconds or less. Para 121 discloses RFID reader 305 controls antenna 310 to interrogate any RFID tags within container 315. In response to the interrogation, the RFID tags communicate information to RFID reader 305 via antenna 310. The communicated information is typically associated with corresponding information stored in a database, such as NDC identifiers, lot numbers, and expiration dates for individual items, and a kit identifier for the kit as a whole. RFID reader 305 communicates the received information to information processing system 115 for storage and/or comparison with a template.)
compare said received item information with said kit instructions to identify whether all required items were present during said scan; (Para 50 discloses a kit template may be located based on the kit type, and then the identified items may be compared with the kit template to determine whether any items are missing or require replacement based on use or expiration. Para 68 discloses one of the most common ways of processing information captured from a kit is comparing the captured information with a template of the kit to determine whether the kit is satisfactorily stocked. The template of a kit defines items that are required to be placed in the kit.)
calculate at least one selected from the group of whether any of said required items were missing, had expired, and had been recalled; (Para 50 discloses a kit template may be located based on the kit type, and then the identified items may be compared with the kit template to determine whether any items are missing or require replacement based on use or expiration. Para 163 discloses system 100 may also automatically inventory items in pharmacy kits to determine where anything is missing, extra, expired, or near expired. This can reduce the chance of manual kit stocking errors or related medical errors in a hospital or other facility. System 100 may also automatically find items for recall in the hospital or emergency medical field kits.)
update said user interface based on information communicated to said server from said RFID reader, barcode reader, and application page comprising said input field and (Para 104 and FIG. 10 disclose interface 1000 may be displayed after a kit is scanned. It displays exceptions in the scanned kit, which are features or occurrences that are deemed to require user notification. In the illustrated example, the exceptions include items that will expire soon, missing items, extra items, and wrong items.)
While MacDonald discloses the above limitations, it does not fully disclose the following limitation that Caputo discloses:
communicate a cart type, earliest cart item expiration date, or both for an inventory cart having at least one kit included therewith to said user computing device; (Paras 26-27 disclose a need has been identified to provide a more efficient and accurate system and method to restock such carts and trays. Crash carts and trays must be resupplied periodically to replace expired or recalled items, and if a cart or a tray was actually used, to replace consumed articles. Para 58 and Fig. 23 discloses the crash cart may be supplied to support a particular use in a healthcare facility, such as the intensive care unit, pediatrics, or other [thus indicating that the carts have types]. Para 134 discloses in the tray database, the tray RFID tag identification is connected with the type and name of the tray and the RFID tag numbers are connected with the medical articles placed in the tray. Trays may have certain categories, such as ER, or ICU, or pediatric, or other, and the tray database will indicate that category for the RFID no. of the tray RFID tag. Para 135 discloses while the embodiment herein described refer to "trays," other container types may function equally well. It is not meant to confine the invention to any particular type of container unless so indicated. Wherein para 142 discloses “a tray, crash cart, or other container” thus indicating that a crash cart is considered another container type. Thus is would have been obvious to implement the a “cart database” that stores the cart RFID tag identification connected with the type and name of the cart.)
wherein said software application is configured to provide at said user interface a real time inventory of said inventory cart. (Para 67 and Fig. 32 disclose a program feature in which the results of scanning a tray are displayed with lists multiple categories of the contents, such as expired, recalled, missing, and others. Para 134 discloses in the tray database, the tray RFID tag identification is connected with the type and name of the tray and the RFID tag numbers are connected with the medical articles placed in the tray. Trays may have certain categories, such as ER, or ICU, or pediatric, or other, and the tray database will indicate that category for the RFID no. of the tray RFID tag. Para 135 discloses while the embodiment herein described refer to "trays," other container types may function equally well. It is not meant to confine the invention to any particular type of container unless so indicated. Wherein para 142 discloses “a tray, crash cart, or other container” thus indicating that a crash cart is considered another container type. Thus is would have been obvious to implement the a “cart database” that stores the cart RFID tag identification connected with the type and name of the cart. Para 142 discloses many different forms of the display of results from scanning a tray, crash cart, or other container may be provided. FIG. 32 is just one embodiment.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the management of pharmacy kits as taught by MacDonald with the real-time inventory re-supply system as taught by Caputo in order to provide a more efficient and accurate system and method to restock [crash] carts and trays (Caputo Para 26).
While the combination of MacDonald and Caputo discloses the above limitations, it does not fully disclose the following limitation that the Stack Overflow reference discloses:
reject input data provided below a speed threshold; (User “testItAll” asked how to implement a system that only allows a user to “edit” through a scan gun to capture a bar code as they wish to prevent the user from adding data via keyboard while still allowing data to be entered via scan. User “Joshua Leonard” answered the question with, “Usually barcode scanners act as a keyboard input, which would prevent you from knowing whether its a keyboard or a scanner. One way to get around this is to check the timing between keypresses. The barcode scanner inputs much faster than a human, and I believe you can modify this speed. If the typing is slow enough [below a speed threshold so you reject it] you'll know its a keyboard. If the typing is within some threshold [above a speed threshold so you don’t reject it] you will know its the scanner.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of the claimed invention to modify the management of pharmacy kits as taught by MacDonald and the real-time inventory re-supply system as taught by Caputo with a threshold as taught by the Stack Overflow reference in order to limit data to that of a scanner instead of a keyboard to increase speed of data collection as well as eliminate human error.
Regarding Claim 10, this claim recites the limitations of Claim 9 and as to those limitations is
rejected for the same basis and reasons as disclosed above. The combination of MacDonald, Caputo, and the Stack Overflow reference further discloses the following limitation that MacDonald further discloses:
The inventory management system of Claim 9 wherein said server, is configured to save information about one or more items not previously encountered by said server in said database. (Para 137-140 and FIG. 15 discloses items arrive at a facility (e.g., a hospital) from a third party manufacturer, distributor, or supplier (605). In some circumstances, the items may have RFID tags when they arrive at the facility. Accordingly, system 100 may scan the items and look up item information from the third party or an additional third party. Such information may include, for example, item master data, item lot data, and item expiration dates. If the items are not already tagged [not previously encountered], item information may be entered into system 100 using a bar code scanner as described above, or by manual user input (610). System 100 associates the unique identifiers with the stored item information (630), allowing the item information to be retrieved subsequently when the RFID tags are scanned. Finally, the RFID tags are attached to corresponding items (635). Para 149 discloses the user may press button 920 to initiate a procedure for capturing item information and printing RFID tags.)
Regarding Claim 11, MacDonald discloses:
An inventory management system comprising:
a web-based inventory management software application having an application page comprising an input field for receiving data manually entered by a user; and receive from said application page comprising said input field information about one or more untagged items; (Para 56 discloses a user interface and one or more software applications allowing a user to access information regarding the status of kits. Para 125-126 discloses computer 405 comprises a browser 410 that receives kit information from the RFID reader via LAN 435 and communicates with server 420 through the internet 415. Para 137 discloses system 100 may scan the items and look up item information from the third party or an additional third party. Such information may include, for example, item master data, item lot data, and item expiration dates. If the items are not already tagged, item information may be entered into system 100 using a bar code scanner as described above, or by manual user input (610) [wherein the ability to manually input data reads on the broadest reasonable interpretation of an application page comprising an input field]. See Further: Paras 144-145.)
a user computing device, configured with instructions to implement said software application and receive said data at a user interface of said software application; (Para 56 discloses a user interface and one or more software applications allowing a user to access information regarding the status of kits [thus disclosing that the user interface is utilizing the software applications to access information].)
a container, configured to store one or more items; (Para 8 discloses a method of managing a pharmacy kit using an electronic information processing system comprises defining, in the electronic information processing system, multiple rules for determining whether a segment of a pharmacy kit is satisfactorily stocked. Para 47 discloses a kit is typically built by placing tagged items in a container such as a box, tray, or canister, and optionally labeling the kit with an RFID tag having information such as a kit identifier, kit type, intended user, or location, for example.)
a barcode reading device and RFID reading device each positioned proximate to said container, and configured to scan a plurality of items in said container; (Para 46 discloses items may arrive at a hospital pre-tagged. One way to tag the items is by scanning bar codes present on most items used in a kit, printing RFID tags based on the scanned bar codes, and then applying the RFID tags to the items. The scanned bar codes typically provide item information such as product identifiers (e.g., NDC or UPC), lot numbers, and expiration dates. This information can be associated with the RFID tags in a computer database to allow subsequent identification and processing by RFID technology. Para 53 discloses the automatic processing provided by RFID technology and associated electronic equipment allows kit management to be performed with greater efficiency and accuracy compared with conventional approaches. For instance, in some embodiments, kit contents and expiration dates can be validated in 15 seconds or less. Para 125-126 discloses referring to FIG. 13, information processing system 115 comprises a computer 405 and a server 420. Computer 405 and server 420 are connected to each other via the internet 415, and computer 405 is connected to an RFID reader, a bar code reader, and an RFID printer through a local area network (LAN) 435.)
a server in communication with said barcode and RFID reading devices, said application page comprising said input field, and a database; (Para 125-126 discloses computer 405 and server 420 are connected to each other via the internet 415, and computer 405 is connected to an RFID reader, a bar code reader, and an RFID printer through a local area network (LAN) 435.). Para 131 discloses Information processing system 115 updates stored records to reflect the scanning (520). In the update, a database in information processing system 115 is updated to reflect the scanned kit contents.)
wherein said server is configured to, based on information communicated to the server from application page comprising said input field and the RFID and barcode reading devices, communicate to said user interface a notification that identifies items in said container that require addition, removal, or both; and (Para 104 and FIG. 10 disclose interface 1000 may be displayed after a kit is scanned. It displays exceptions in the scanned kit, which are features or occurrences that are deemed to require user notification. In the illustrated example, the exceptions include items that will expire soon, missing items, extra items, and wrong items [require addition, removal, or both].)
While MacDonald discloses the above limitations and barcode and RFID reading devices working in tandem (See MacDonald para 46), it does not fully disclose the following limitation that Caputo discloses:
wherein said server comprises hardware configured to receive, from the [barcode] and RFID reading devices, information about cart type, earliest cart item expiration date, or both for an inventory cart having at least one container included therewith; (Para 3 discloses there are a number of ways of identifying and tracking articles including visually, optically (bar coding, for example)…RFID… and others. Paras 26-27 disclose a need has been identified to provide a more efficient and accurate system and method to restock such carts and trays. Crash carts and trays must be resupplied periodically to replace expired or recalled items, and if a cart or a tray was actually used, to replace consumed articles. Para 58 and Fig. 23 discloses the crash cart may be supplied to support a particular use in a healthcare facility, such as the intensive care unit, pediatrics, or other [thus indicating that the carts have types]. Para 134 discloses in the tray database, the tray RFID tag identification is connected with the type and name of the tray and the RFID tag numbers are connected with the medical articles placed in the tray. Trays may have certain categories, such as ER, or ICU, or pediatric, or other, and the tray database will indicate that category for the RFID no. of the tray RFID tag. Para 135 discloses while the embodiment herein described refer to "trays," other container types may function equally well. It is not meant to confine the invention to any particular type of container unless so indicated. Wherein para 142 discloses “a tray, crash cart, or other container” thus indicating that a crash cart is considered another container type. Thus is would have been obvious to implement the a “cart database” that stores the cart RFID tag identification connected with the type and name of the cart.)
wherein said software application is configured to provide at the user interface a real time inventory of said inventory cart. (Para 67 and Fig. 32 disclose a program feature in which the results of scanning a tray are displayed with lists multiple categories of the contents, such as expired, recalled, missing, and others. Para 134 discloses in the tray database, the tray RFID tag identification is connected with the type and name of the tray and the RFID tag numbers are connected with the medical articles placed in the tray. Trays may have certain categories, such as ER, or ICU, or pediatric, or other, and the tray database will indicate that category for the RFID no. of the tray RFID tag. Para 135 discloses while the embodiment herein described refer to "trays," other container types may function equally well. It is not meant to confine the invention to any particular type of container unless so indicated. Wherein para 142 discloses “a tray, crash cart, or other container” thus indicating that a crash cart is considered another container type. Thus is would have been obvious to implement the a “cart database” that stores the cart RFID tag identification connected with the type and name of the cart. Para 142 discloses many different forms of the display of results from scanning a tray, crash cart, or other container may be provided. FIG. 32 is just one embodiment.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the management of pharmacy kits as taught by MacDonald with the real-time inventory re-supply system as taught by Caputo in order to provide a more efficient and accurate system and method to restock [crash] carts and trays (Caputo Para 26) and tag the items by scanning bar codes present on most items used in a kit, printing RFID tags based on the scanned bar codes, and then applying the RFID tags to the items in order to allow subsequent identification and processing by RFID technology (MacDonald Para 46).
While the combination of MacDonald and Caputo discloses the above limitations, it does not fully disclose the following limitation that the Stack Overflow reference discloses:
reject input data provided below a speed threshold; (User “testItAll” asked how to implement a system that only allows a user to “edit” through a scan gun to capture a bar code as they wish to prevent the user from adding data via keyboard while still allowing data to be entered via scan. User “Joshua Leonard” answered the question with, “Usually barcode scanners act as a keyboard input, which would prevent you from knowing whether its a keyboard or a scanner. One way to get around this is to check the timing between keypresses. The barcode scanner inputs much faster than a human, and I believe you can modify this speed. If the typing is slow enough [below a speed threshold so you reject it] you'll know its a keyboard. If the typing is within some threshold [above a speed threshold so you don’t reject it] you will know its the scanner.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of the claimed invention to modify the management of pharmacy kits as taught by MacDonald and the real-time inventory re-supply system as taught by Caputo with a threshold as taught by the Stack Overflow reference in order to limit data to that of a scanner instead of a keyboard to increase speed of data collection as well as eliminate human error.
Regarding Claim 12, this claim recites the limitations of Claim 11 and as to those limitations is
rejected for the same basis and reasons as disclosed above. The combination of MacDonald, Caputo, and the Stack Overflow reference further discloses the following limitation that MacDonald discloses:
The system of claim 11, wherein said information communicated to said server from said RFID reading device is communicated to said server automatically after an RFID tag is scanned and determined to contain proper information. (Para 53 discloses the automatic processing provided by RFID technology and associated electronic equipment allows kit management to be performed with greater efficiency and accuracy [contain proper information] compared with conventional approaches. Para 57 discloses the kit management system can provide more efficient verification and recording of kit contents, and more accurate monitoring of kits, items, and expiration dates. Para 65 discloses system 100 comprises an information processing system 115 and an RFID reading station 110. System 100 is configured to automatically read and process information from a pharmacy kit 105. Paras 125-126 disclose information processing system 115 comprises a computer 405 and a server 420. Computer 405 and server 420 are connected to each other via the internet 415, and computer 405 is connected to an RFID reader, a bar code reader, and an RFID printer through a local area network (LAN) 435. Computer 405 comprises a browser 410 that receives kit information from the RFID reader via LAN 435 and communicates with server 420 through the internet 415. Server 420 stores templates 425, which typically include kit master templates and item master templates. Server 420 also stores records 430, which include information regarding individual kits and items.)
Regarding Claim 13, this claim recites the limitations of Claim 11 and as to those limitations is
rejected for the same basis and reasons as disclosed above. The combination of MacDonald, Caputo, and the Stack Overflow reference further disclose the following limitation that MacDonald further discloses:
The system of claim 11, wherein said software application is configured to flag a recalled lot and (Para 77 discloses the received item master data could indicate, for example, that an item has been recalled or changed in some material respect. Para 152 discloses system 100 may also automatically find items for recall in the hospital or emergency medical field kits.)
block further intake to said recalled lot (Para 187 discloses if the at least one contextual attribute indicates that a drug is expired or recalled, the method may block a user from performing a subsequent step of a workflow and/or display a warning.)
Regarding Claim 14, this claim recites the limitations of Claim 11 and as to those limitations is
rejected for the same basis and reasons as disclosed above. The combination of MacDonald, Caputo, and the Stack Overflow reference further discloses the following limitation that MacDonald discloses:
The system of claim 11, wherein said container is a kit. (Para 8 discloses a method of managing a pharmacy kit using an electronic information processing system comprises defining, in the electronic information processing system, multiple rules for determining whether a segment of a pharmacy kit is satisfactorily stocked. Para 47 discloses a kit is typically built by placing tagged items in a container such as a box, tray, or canister, and optionally labeling the kit with an RFID tag having information such as a kit identifier, kit type, intended user, or location, for example.)
Regarding Claim 15, this claim recites the limitations of Claim 11 and as to those limitations is
rejected for the same basis and reasons as disclosed above. The combination of MacDonald, Caputo, and the Stack Overflow reference further discloses the following limitation that Caputo discloses:
The system of claim 11, wherein said container is an inventory cart drawer. (Para 21 and Fig. 23 discloses an example of a crash cart 300. Such carts usually include wheels 302 so that they are mobile and may have multiple drawers 304 in which various medical articles are stored. Para 38 and FIG. 3 discloses a block and flow diagram showing an embodiment in which an RFID reader transmits activating EM energy into a drawer containing RFID tags with a single transmitting antenna, receives the data output from the activated RFID tags with a single receiving antenna, a computer controlling the transmission of activating energy and receiving the data from the activated RFID tags for processing.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of the management of pharmacy kits as taught by MacDonald and the threshold as taught by the Stack Overflow reference with the real-time inventory re-supply system as taught by Caputo in order to provide a more efficient and accurate system and method to restock [crash] carts and trays (Caputo Para 26).
Response to Arguments
Applicant’s arguments filed 1/26/2026 with respect to 35 U.S.C. § 112(a) have been fully considered, and are persuasive in light of the removal of the limitations that were previously rejected under 112(a). Therefore, the previous 112(a) rejection has been withdrawn.
Applicant’s arguments filed 1/26/2026 with respect to 35 U.S.C. § 101 have been fully considered, but are not persuasive.
The Applicant argues that the claimed invention does not organize human activity and that none of the limitations can be performed mentally. The Applicant further states that the claimed invention recites a computer-implemented inventory management system that fuses barcode, RFID and manual-entry data to adjust a user interface, and to provide real time inventory of an inventory cart in real time. First, the Examiner submits that the abstract idea was not characterized as being directed to a mental process. Second, the Examiner submits that the identified claim elements represent a series of rules or instructions that a person or persons, with or without the aid of a computer (a computing device, server, or a bar code or RFID reading device), would follow to update kit/cart/container inventory (including when and how). Because the claim elements fall under a series of rules or instructions that a person or persons would follow to update kit/cart/container inventory (including when and how), the claimed invention is directed to an abstract idea. As such, this argument is not persuasive.
The Applicant then argues that the claimed invention provides a specific technological solution to a non-business problem in a particular field. The Examiner respectfully disagrees. MPEP 2106.04(d)(1) and MPEP 2106.05(a) indicates that a practical application may be present where the claimed invention provides a technical solution to a technical problem. See, e.g., DDR Holdings, LLC. v. Hotels.com, L.P., 773 F.3d 1245, 1259 (Fed. Cir. 2014) (finding that claiming a website that retained the “look and feel” of a host webpage provided a technological solution to the problem of retention of website visitors by utilizing a website descriptor that emulated the “look and feel” of the host webpage, where the problem arose out of the internet and was thus a technical problem). Here, the Applicant’s argued problem is not a technological problem caused by the technological environment to which the claims are confined. The problem of a lack of mixed-modality, live inventory tracking, as discussed in the Applicant’s specification paras. 5-10 (to briefly summarize: a need for tracking inventory quantity and location and expired/recalled medicines) was not a problem caused by the user computing device, server, or readers (barcode or RFID) that is involved in the process and is instead a business problem in the medical industry (expired/recalled medicines).
Further, the Applicant disagrees that the claimed invention involves mere application of an abstract idea to a generic computer and that the server-implemented reconciliation of barcode, RFID, and manual-entry data to update a user interface in real time “improves how the computing devices and server operate by optimizing data ingestion, consolidation, and communication for inventory management purposes.” The Examiner respectfully disagrees. “Optimizing data ingestion, consolidation, and communication for inventory management purposes” by simply receiving data from a barcode reader, an RFID reader, and manually and storing the data in a database does not provide an improvement to the computing devices and server. Further, the Applicant argues that “presenting of cart information at the user interface in real time… improves the speed of inventory communication.” The Examiner does not disagree that presenting information in real time improves the speed of communicating the information. However, this is not an improvement of a computer or other technology. Further, the Applicant argues that the automatic intake of pre-tagged items “improves the speed of data input and avoid the need for a user to first create the item or otherwise approve the item for use.” The Examiner notes that paragraph 64 also discloses, “Automatic inputting of pre-tagged drugs may be permitted only when the RFID tags contain pre-determined necessary information (e.g., drug name, lot number, expiration date),” thus indicating that the RFID tag and reader is how the system automatically intakes the pre-tagged items. The Examiner notes that the Applicant has not invented a new way for the RFID tags or readers to store or scan information. The Applicant is simply applying the RFID tags or readers to implement the abstract idea. Thus, “improving the speed of data input” is merely stating that the use of RFID allows for quicker uptake of data and thus the RFID tag or reader are performing as expected, they are not improved in any way. Further, in regards to the newly added amendment of the speed threshold for data entry, the Applicant states that “paragraph 82 discusses this input speed gating option for reducing latency and errors in data capture.” The Examiner notes that specifically paragraph 82 states, “this feature [the certain threshold of speed restricting input to only be made by barcode] may reduce the amount of human error caused during manual entry of information.” As such, this limitation is not providing an improvement to a computer or technology. It is merely limiting data input to that of data from a barcode. The human error was not a problem caused by the computer or another technology, it is exactly that, an error caused by a human inputting information. Applying a barcode and scanner to gather information instead of a human does not provide a practical application or significantly more. Further, the Applicant argues that MPEP 2106.04(D)(1) or 2106.05(a) do not require that proof of a physical improvement to the hardware itself, or proof that said hardware runs faster must be provided. The Examiner respectfully disagrees. MPEP 2106.04(D)(1) recites, “a detailed explanation of how examiners should evaluate this consideration are provided in MPEP § 2106.05(a). In short, first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art. Conversely, if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology.” As discussed in detail above in regards to each argument, the Examiner, one of ordinary skill in the art, disagrees that the claims invention improves the computing device, server, or any other technology and therefore the claimed invention does not provide a practical application.
Finally, the Applicant argues that the claimed invention provides significantly more because it involves server-implemented reconciliation of barcode, RFID, and manual-entry healthcare inventory data to update a user interface in real time “which is not well-understood, routine, or conventional in the field,” and further states that the input speed gating (in regards to the speed threshold) is not well-understood, routine or conventional in the field. MPEP 2106.05(d)(I) indicates that in determining whether the additional elements represent well-understood, routine, conventional activities, the Examiner should consider whether the additional elements (1) provide an improvement to the technological environment to which the claim is confined, (2) whether the additional elements are mere instructions to apply the judicial exception, or (3) whether the additional elements represent insignificant extra-solution activity. The additional elements of the claims do not provide significantly more based on this inquiry.
Taking these in turn, the technological environment to which the claims are confined (a server that may be any configuration of hardware and software that can perform the functions discussed [see Spec. Para. 88]) is recited at a high level of generality such that it amounts to no more than mere instructions to implement an abstract idea by adding the words ‘apply it’ (or an equivalent with the judicial exception. There is no level of detail of how the server is improved. Further, none of the additional elements of the claim were found to represent extra-solution activity and thus no-well-understood, routine, conventional analysis is required.
Applicant’s arguments filed 06/24/2025 with respect to 35 U.S.C. § 103 have been fully considered.
In regards to the newly added limitation of “reject[ing] input data provided below a speed threshold,” the argument is persuasive. Therefore, the previous 35 U.S.C. § 103 rejection has been withdrawn. However, upon further consideration, a new grounds of rejection under 35 U.S.C. § 103 necessitated by Applicant’s amendments as disclosed above.
However, regarding the remaining arguments, the arguments have been considered, but are not persuasive. The Applicant disagrees with page 21 of the office action that Caputo teaches updating said user interface based on said first second and third information. The Examiner notes that the claim language discloses that the first item and second item information comprise at least one selected from the group of identification information, expiration information, and lot number information and the third item information comprises information about one or more untagged items. Para 142 and Fig. 32 of Caputo discloses a computer program screen shot 540 of a listing of the articles detected in a tray during a scan of that tray. Various categories are shown including expiration 542 [expiration information] and recall 544. Wherein Fig. 32 discloses Item Name, dose, and number of items under each section [thus disclosing identification information]. Further, as previously presented, while Caputo discloses “a computer program screen shot 540 of a listing of the articles detected in a tray during a scan of that tray in accordance with aspects of the invention (Para 142 and Fig. 32) and, “a user may instruct the inventory management system 410 through an input device 428 [manual entry module], to register the container [untagged items] under a certain category.” (Para 150). Further, Para 150 of Caputo discloses, “the user may insert the medical container into the enclosure of the inventory management system, such as described above in FIG. 28 at numeral 41. A user may instruct the inventory management system 410 through an input device 428, to register the container under a certain category, including specialized and/or individualized categories. The system may read identification data from every data carrier within the enclosure. In one embodiment, a data carrier is attached to the medical container itself. The system 410 may search a database for medical information associated with each identification data read from the data carriers within the container.” As such, Figure 28 and associated paragraphs indicate that the databases are built by registering the items and thus listing the articles detected in a tray during a scan (of para 142) is updated based on the information about one or more untagged items. However, as previously presented, Caputo does not fully disclose the web-based inventory management software application having a manual entry module for receiving data entered by a user; receive from said manual entry module third item information comprising information about one or more untagged items wherein specifically the information about one or more untagged items is entered manually. Instead, the Examiner utilized MacDonald to read on this limitation.
The Applicant then argues that neither Caputo nor MacDonald discuss receiving barcode, RFID, and manual-entry data, storing them together, and updating a user interface to provide a real-time inventory of an inventory cart. The Examiner notes that the combination of Caputo and MacDonald was used to read on the limitations of the claimed invention as previously presented and thus the claimed invention is rejected under 35 U.S.C 103 and not under 35 U.S.C 102.
Next, the Applicant argues that Caputo does not indicate that the required inventory list is a real-time inventory of an inventory cart. Caputo para 30 discloses, “those skilled in the art have recognized a need for an improved real-time inventory system for managing medical article container systems. Additionally, a need has been recognized for performing such article management with a more compact, self-contained wireless reader system that reduces the space needed to inventory crash carts and trays. A further need has been recognized for confining the energy used for reading wireless medical article identification devices to a particular area so that accuracy of identification is obtained. The present invention fulfills these needs and others.” Further, as previously presented Para 142 and Fig. 32 disclose, “a computer program screen shot 540 of a listing of the articles detected in a tray during a scan of that tray in accordance with aspects of the invention. Various categories are shown including expiration 542 and recall 544. Incorrect articles 546 may be listed and for convenience, the entire Required Inventory list can be displayed as well as a check mark next to each one that is present and not expired. Many different forms of the display of results from scanning a tray, crash cart, or other container may be provided. FIG. 32 is just one embodiment.” The check mark next to each required inventory list item that is present and not expired thus reads on providing “at said user interface a real time inventory of said inventory cart.”
Further, the Applicant argues that the motivation to integrate a barcode reader to Caputo is lacking and that Caputo teaches it prefers RFID only and further argues that the cited portion of MacDonald does not teach a barcode reader and updating the user interface based on the first, second, and third item information. The Examiner respectfully disagrees. Caputo teaches the use of RFID but it does not explicitly say that a barcode cannot be used. Specifically, in light of MacDonald, it would have been obvious to modify the real-time re-supply system as taught by Caputo with the barcode reader as taught by MacDonald in order to tag the items that arrive with bar codes but do not arrive pre-tagged with RFID tags by printing RFID tags based on the scanned bar codes and then applying the RFID tags to the items in order to allow subsequent identification and processing by RFID technology (MacDonald Para 46).
Regarding claim 2, the Applicant argues that the cited reference does not teach or suggest said server is configured to receive information about items present in said bin during a scan, and compare said information about items present in said bin during a scan with identification information stored in said database, and provide a bin notification to a user based on the comparison. The Examiner respectfully disagrees. As previously presented Para 42 of Lunak discloses identifying the contents of the bin [information about items present in bin] and para 46 discloses a workstation 62 is in communication with the database and receives information from the database regarding items, and quantities for each item, needed to replenish each of the decentralized storage locations.” Thus, Lunak reads on a comparison because it identifies the contents of the bin and then identifies the items and quantities for each item that needs to be replenished. The Applicant then argues the amendment that the notification is not based on the comparison. However, Para 46 discloses, “the workstation 62 receives information from the database regarding items, and quantities for each item, needed to replenish each of the decentralized storage locations 12-1 through 12-n or to fulfill patient dispenses. The workstation 62 processes the information and presents to the user through a screen 64 a series of operations referred to as "picks". The information displayed on the screen may include, for example, an identification of the decentralized storage location, an identification of a cabinet, tower, shelving unit, etc. at the decentralized location, an identification of the patient, the item and quantity to be picked [bin notification based on the comparison].” Therefore, this argument is not persuasive.
In regards to claim 6, the Applicant argues the amendment that the location of said inventory cart, cart type of said inventory cart, and an expiration date of said kit are provided is not taught or suggested by the cited references. The Examiner respectfully disagrees, the claim has been updated above in light of the amendment requiring the cart type and the expiration date of the kit and citations and motivations are presented for the cited references.
In regards to claim 10, the Applicant argues that MacDonald does not disclose saving information about items not previously encountered. The Examiner respectfully disagrees. As previously presented, Paras 137-140 and FIG. 15 disclose, “if the items are not already tagged [not previously encountered], item information may be entered into system 100 using a bar code scanner as described above, or by manual user input (610). System 100 associates the unique identifiers with the stored item information (630) [saving the information about items not previously encountered], allowing the item information to be retrieved subsequently when the RFID tags are scanned. Finally, the RFID tags are attached to corresponding items (635).” Wherein MacDonald discloses that the information associated with tag information is stored in a computer database (See Para 66-67, 121, 168). As such, this argument is not persuasive.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SARA J MORICE DE VARGAS whose telephone number is (703)756-4608. The examiner can normally be reached M-F 8:30-5:30 pm.
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, Peter H. Choi can be reached on (469)295-9171. 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.
/SARA JESSICA MORICE DE VARGAS/Examiner, Art Unit 3681
/PETER H CHOI/Supervisory Patent Examiner, Art Unit 3681
Prosecution Insights