DETAILED ACTION
This communication is a Final Rejection Office Action in response to the 3/30/2026 filling of Application 18/604,088. Claims 13-25 are now presented.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s remaining arguments with respect to the prior art have been considered but are moot because the new ground of rejection does not apply to the new grounds or rejection that was necessitated by amendment.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 13-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Masanam US 2024/0029525 A1 in view of Somani US 2016/0034723 A1.
As per claim 13 Masanam teaches A testing assembly for automated testing of a consumer experience of a tested machine, the assembly comprising: Masanam para. 6 teaches in an exemplary embodiment, a system for testing a point-of-sale (POS) device including a card stack mechanism having a plurality of card stacks configured to hold a plurality of cards, a card insert-pay mechanism configured to insert one of the plurality of cards into the POS device to be tested, a card swipe-pay mechanism configured to swipe one of the plurality of cards into the POS device to be tested, and a card screen pin-pad mechanism configured to select a key on a keypad or an operation displayed on a display of the POS device associated with one of the card insert-pay mechanism or the card swipe-pay mechanism.
a testing rig for a user interface of the tested machine, wherein the user interface is a point of sale interface, and wherein the testing rig comprises: a card holder configured to submit a payment card to the user interface of a tested machine, and Masanam para. 6 teaches in an exemplary embodiment, a system for testing a point-of-sale (POS) device including a card stack mechanism having a plurality of card stacks configured to hold a plurality of cards, a card insert-pay mechanism configured to insert one of the plurality of cards into the POS device to be tested, a card swipe-pay mechanism configured to swipe one of the plurality of cards into the POS device to be tested, and a card screen pin-pad mechanism configured to select a key on a keypad or an operation displayed on a display of the POS device associated with one of the card insert-pay mechanism or the card swipe-pay mechanism.
Masanam does not teach a sensor configured to measure the tested machine’s response to submission of the payment card to the user interface. However, Somani para. 41 teaches Additionally, or alternatively, a configuration parameter may specify a manner in which test robot 220 is to monitor feedback from card reader device 240 (e.g., after fare card 230 is brought within communicative proximity of card reader device 240). For example, once fare card 230 is brought within communicate proximity of card reader device 240, card reader device 240 may provide haptic feedback (e.g., may open a turnstile, may prevent a turnstile from opening, may open a door, may prevent a door from opening, etc.), may emit audible feedback (e.g., a beep, a voice instruction, etc.), may emit visual feedback (e.g., a green light to indicate a successful interaction with fare card 230, a red light to indicate a failed interaction with fare card 230, a message displayed on a digital display, etc.), may transmit a communication (e.g., a near-field communication), or the like. Test robot 220 may monitor one or more such feedback in a manner indicated by a configuration parameter. Further, para. 24 teaches test robot 220 (sometimes referred to herein as a T-Bot) may include one or more devices capable of receiving, generating, storing, processing, analyzing, and/or providing information associated with testing an automated fare management system. For example, test robot 220 may include a robot. In some implementations, test robot 220 may include, for example, a processor for processing instructions (e.g., for executing a test scenario), a fare card reader to read card information from fare card 230, a fare card writer to write information to fare card 230, one or more actuators to move fare card 230 into a communicative proximity of card reader device 240 (e.g., an actuator arm, a robotic arm, a piston, a motor, etc.), one or more sensors to detect feedback from card reader device 240 (e.g., a light sensor, an audio sensor, a haptic sensor, an image processing component, a microphone, etc.), a display component to display information (e.g., card information), a communication interface (e.g., Wi-Fi, Bluetooth, Ethernet, etc.) to communicate with other devices (e.g., test management device 210, card reader device 240, a back office server device, etc.), or the like.
an automated door opener configured to open and close a door of the tested machine; wherein the door opener is configured to be controlled in cooperation with the testing rig to enable testing of functionality related to the door. Somani para. 41 teaches Additionally, or alternatively, a configuration parameter may specify a manner in which test robot 220 is to monitor feedback from card reader device 240 (e.g., after fare card 230 is brought within communicative proximity of card reader device 240). For example, once fare card 230 is brought within communicate proximity of card reader device 240, card reader device 240 may provide haptic feedback (e.g., may open a turnstile, may prevent a turnstile from opening, may open a door, may prevent a door from opening, etc.), may emit audible feedback (e.g., a beep, a voice instruction, etc.), may emit visual feedback (e.g., a green light to indicate a successful interaction with fare card 230, a red light to indicate a failed interaction with fare card 230, a message displayed on a digital display, etc.), may transmit a communication (e.g., a near-field communication), or the like. Test robot 220 may monitor one or more such feedback in a manner indicated by a configuration parameter. Both Masanam and Somani are directed to performing tested on equipment. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Masanam to include a sensor configured to measure the tested machine’s response to submission of the payment card to the user interface and an automated door opener configured to open and close a door of the tested machine; wherein the door opener is configured to be controlled in cooperation with the testing rig to enable testing of functionality related to the door as taught by Somani to assist in automating the testing of automated fare management systems, which may reduce the amount of time required to perform the tests and may increase the accuracy of test results (see para. 17).
As per claim 14 Masanam teaches the testing assembly of claim 13, comprising a stylus configured to simulate manual inputs to the user interface. Masanam para. 49 teaches referring now to FIG. 3, the screen pin-pad mechanism 400 of system 10 includes a gantry system 410 configured to allow an input device 450 (as shown in FIG. 10A) to move translationally along at least one of three axes (e.g., X, Y, Z) over the POS terminal 50. By way of example, after the card 20 has been interfaced with the POS terminal 50 via the card insert-pay mechanism 200, the controller instructs the input device 450 based on the inserted microprocessor chip to provide an input (i.e., a code, a pin, a zip code, a telephone number, a date of birth, etc.). For example, the controller may instruct the input device 450 to “enter pin” or “provide pin”, which may be a 4-digit PIN used to authorize a transaction associated with the card. To this end, the controller may instruct the input device 450 to interface with and move towards a keypad 51 on the POS terminal 50, as shown in FIGS. 12A and 12B. In some implementations, the input device 450 may include a stylus or pen 451 to press keys/button on the keypad 51. The controller may align the stylus or pen 451 over the keypad 51, so that the stylus 451 is aligned directly over the respective keys on the keypad 51 for entering data. In some implementations, at a distal end of the stylus 451, a tip 455 made from rubber, for example, is attached to provide padding, non-slip resistance, and/or reduce fatigue to the keys/buttons. After the code on the keypad 51 has been input, the input device 450 then presses, for example, an “enter” button or “end” button to submit the code and complete the transaction. When the current status of the POS terminal 50 changes to “transaction complete,” the controller instructs the input device 450 to return back to its original or resting position of the gantry system 410.
As per claim 15 Masanam teaches the testing assembly of claim 13, comprising a motorized arm configured to submit the payment card to the user interface by swiping a magnetic strip of the payment card through a magnetic strip reader of the user interface. Masanam para. 6 teaches in an exemplary embodiment, a system for testing a point-of-sale (POS) device including a card stack mechanism having a plurality of card stacks configured to hold a plurality of cards, a card insert-pay mechanism configured to insert one of the plurality of cards into the POS device to be tested, a card swipe-pay mechanism configured to swipe one of the plurality of cards into the POS device to be tested, and a card screen pin-pad mechanism configured to select a key on a keypad or an operation displayed on a display of the POS device associated with one of the card insert-pay mechanism or the card swipe-pay mechanism.
As per claim 16 Masanam teaches the testing assembly of claim 15, comprising an actuator configured to push a chip of the payment card into a chip reader of the user interface. Masanam para. 29-30 teaches in some implementations, the proposed system of the present disclosure can combine testing of multiple features of the POS system, for example, inserting of EMV chip cards, swiping cards with EMV chip and magnetic strip, and testing pin-pad and touch screen, with an opportunity to choose from a list of available electronic card types (i.e., credit cards, debit cards, stored value cards, gift cards, etc.). FIG. 1 is a schematic view of a point-of-sale (POS) testing automation system 10, according to an example embodiment. The system 10 includes a card stack mechanism 100 for holding a plurality of cards 20, a card insert-pay mechanism 200 configured to insert one of the plurality of cards 20 into a POS terminal 50 to be tested, a card swipe mechanism 300 configured to swipe one of the plurality of cards 20 into the POS terminal 50 to be tested, and a screen pin-pad mechanism 400 configured to select an operation on a keypad 51 or displayed on a display 52 of the POS terminal 50 associated with one of the card insert-pay mechanism 200 or the card swipe mechanism 300.
As per claim 17 Masanam teaches The testing assembly of claim 13, comprising a frame to which the arm is connected, wherein the frame is configured for mounting to the user interface. Masanam para. 36 teaches Referring to FIGS. 2A and 2B, the card stack mechanism 100 includes a first card stack 111 and a second card stack 112 for storing a plurality of cards 20 and an elevator 115 to move the first arm 70 in a vertical direction (i.e., up-and-down). In some implementations, the elevator 115 is arranged between the first card stack 111 and the second card stack 112. The elevator 115 supports the first arm 70 on a platform 117 and enables the first arm 70 to engage one of the plurality of cards 20 stored in either the first or second card stacks 111, 112. In other words, the elevator 115 moves the platform 117 up or down to enable the first arm 70 to select one of the plurality of cards 20 stored in either of the first or second card stacks 111, 112. For example, if the associated card 20a located near a top portion of the first card stack 111 is selected to be tested, the elevator 115 moves to the location of the associated card 20a and enables the first arm 70 to turn towards the first card stack 111 and grab the associated card 20a located near the top portion of the first card stack 111. Once the associated card 20a is grabbed, the elevator 115 moves down to its starting position to transfer the associated card 20a to either the second arm 80 or the third arm 90 which is to be delivered to the respective card insert-pay mechanism 200 or the card swipe mechanism 300. In some implementations, each of the first and second card stacks 111, 112 includes slots 127 for storing the plurality of cards 20 in a vertical stack configuration. In one implementation, each of the first card stack 111 and the second card stack 112 can have 11 slots 127 to store up to 11 cards, as shown in FIGS. 6A and 6B. In other implementations, the first card stack 111 and the second card stack 112 can have different number of slots 127 for storing the cards 20, as shown in FIG. 2A. By way of example, the first card stack 111 can have 11 slots 127 for storing 11 cards 20 and the second card stack 112 can have 8 slots 127 for storing only 8 cards 20. In this implementation, the second card stack 112 has a receiving area 135 for transferring the associated card 20a from the first arm 70 to the second arm 80. In other words, after the associated card 20a has been retrieved by the first arm 70, the receiving area 135 enables a space for transferring the associated card 20a to the second arm 80. That is, the first arm 70 positions the associated card 20a such that the second arm 80 may retrieve the associated card 20a that is currently gripped by the first arm 70. To this end, the first arm 70 and the second arm 80 are aligned such that the arms 70, 80 have the same Y-coordinates and same orientations.
Masanam does not explicitly disclose comprising a frame to which the arm and the sensor are connected. However, Friedel para 21 teaches In an embodiment, at least some components of the fuel pump simulator are acquired from a fuel pump manufacturer as an off-the-shelf product, and a qualified service person disassembles that equipment, at least partially, to enable mounting robots in jigs to interact with fuel pump controls and to enable mounting one or more cameras in shielding boxes over the several displays. The PIN pad of the fuel pump simulator is mounted at an angle of between 30 degrees relative to horizontal and 60 degrees relative to horizontal. The PIN entry robot is mounted with a jig or fixture at an angle between 30 degrees relative to horizontal and 60 degrees relative to horizontal to match the angle of the PIN pad of the fuel pump simulator. In an embodiment, relays are substituted in place of the fuel grade selection buttons of the fuel pump simulator, wired into the fuel pump simulator, and controlled by the fuel pump test integration subsystem. Both Masanam and Friedel are directed to testing POS systems. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Masanam to include a frame to which the arm and the sensor are connected the use of sensors as taught by Friedel to assure a higher level of accuracy in the testing process (see para. 19).
Claim(s) 18, 19, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Masanam US 2024/0029525 A1 in view of Somani US 20160034723 A1in view of Friedel US 2022/0194775 A1.
As per claim 18 Masanam teaches the testing assembly of claim 13, comprising a near field communication (“NFC”) chip and Masanam para. 31 teaches each of the plurality of cards 20 includes a first transaction type and a second transaction type that are implemented in the POS terminal 50. In one implementation, the first transaction type is an interface mode for a microprocessor chip (e.g., Europay, Mastercard and Visa (EMV) chip cards) and the second transaction type is an interface mode for a magnetic strip (e.g., magstrip cards). When the interface mode is the microprocessor chip, the card 20 can be inserted or “dipped” into a card reader 55 of the POS terminal 50. When the interface mode is the magnetic strip, the card 20 can be swiped (or slid) into a card reader 57 of the POS terminal 50. In some implementations, the card 20 can include a third transaction type that is an interface mode for a contactless scan including NFC-enabled digital wallets such as Apple Pay and Google Pay. In this implementation, the card 20 is tapped or hovered over an associated card reader of the POS terminal 50. Examples of the cards 20 may include, but not limited to, credit cards, debit cards, gift cards, loyalty cards, prepaid cards forex cards, or similar electronic cards.
Masanam does not explicitly disclose a motorized chip bracket configured to move the chip into and out of a communication range of an NFC reader of the interface. However, Friedel para. 36 teaches in an embodiment, the memory 152 comprises a non-transitory portion that stores an application 154, a plurality of test cases 156, and a plurality of test case results 158 (e.g., after at least some of the test cases 156 have been executed by the application 154). When executed by the processor 150, the application 154 automatically tests the fuel pump simulator 104 in accordance with at least some of the test cases 156, analyzes the results of executing the test cases 156, and generates test case results 158 based on analyzing the results of executing the test cases 156. While executing a test case 156, the application 154 sends commands and/or control signals to one or more of the main display keys robot 134, the PIN entry robot, 136 the payment card entry robot 138, the NFC stimulus device 142, and the relays 126 to interact with the fuel pump simulator 104, for example in a manner similar to a customer at a real fuel pump would interact with the payment card reader 118, the main display keys 114, the PIN pad 116, the NFC reader 122, and the fuel grade select pushbuttons (here replaced by some of the relays 126). Both Masanam and Friedel are directed to testing POS systems. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Masanam to include a motorized chip bracket configured to move the chip into and out of a communication range of an NFC reader of the interface as taught by Friedel to speed up the testing process, reduce the labor costs associated with conducting the tests, assure a higher level of accuracy in the testing process, and free valuable subject matter experts for other important activities (See para. 19).
As per claim 19 Masanam in view of Somani does not teach the testing assembly of claim 13, wherein the sensor is a camera. However, Friedel para. teaches the test environment comprises a fuel pump simulator that has been partially disassembled and a fuel pump test platform that actuates the fuel pump simulator to test functionality of software installed in the fuel pump simulator and/or in a point-of-sale backend associated with the fuel pump. In an embodiment, the fuel pump simulator comprises a fuel computer that emulates a computer installed at fuel stations that may control the actions of a plurality of fuel pumps at the same fuel station location. In an embodiment, the fuel pump test platform comprises a PIN entry robot to actuate PIN pad keys of the fuel pump simulator, a payment card entry robot to present a payment card to a payment card reader of the fuel pump simulator, a near field communication (NFC) reader, and a plurality of cameras to capture images of a plurality of displays of the fuel pump simulator. The fuel pump test platform further comprises a fuel pump test integration subsystem that executes a test application to command the robots to provide inputs to the fuel pump simulator, monitors the images provided by the cameras, and analyzes information captured in the images to determine a pass/fail result of running test cases. Both Masanam in view of Somani and Friedel are directed to testing POS systems. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Masanam in view of Somani to include wherein the sensor is a camera as taught by Friedel to speed up the testing process, reduce the labor costs associated with conducting the tests, assure a higher level of accuracy in the testing process, and free valuable subject matter experts for other important activities (See para. 19).
As per claim 20 Masanam does not teach The testing assembly of claim 19, configured to determine whether the interface provides expected feedback to an action performed by the rig and recording feedback provided by the interface. However, Friedel para 36 teaches the application 154 monitors feedback from the fuel pump simulator 104 by receiving one or more pictures of the main display 112 sent by the main display camera 132, by receiving one or more pictures of the fuel display 124 sent by the fuel display camera 144, and by receiving one or more pictures of the fuel grade price displays 120 sent by the fuel grade price display cameras 140. The application 154 compares the feedback received from the cameras 132, 140, 144 and compares these results to expected results defined by the currently executing test case 156 to determine the corresponding test case result 158. If the received feedback is different than the expected results, the test case result 158 may be deemed a failure; if the received feedback is identical to the expected results, the test case result 158 may be deemed a success. Both Masanam and Friedel are directed to testing POS systems. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Masanam to include determine whether the interface provides expected feedback to an action performed by the rig and recording feedback provided by the interface as taught by Friedel to speed up the testing process, reduce the labor costs associated with conducting the tests, assure a higher level of accuracy in the testing process, and free valuable subject matter experts for other important activities (See para. 19).
Claim(s) 21-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Masanam US 2024/0029525 A1 in view of Somani US 20160034723 A1 in view of Rivoir US 2022/0253375 A1.
As per claim 21 Masanam teaches A system comprising:
testing rig for a user interface of the tested machine, wherein the user interface is a point of sale interface, the testing rig comprising: Masanam para. 6 teaches in an exemplary embodiment, a system for testing a point-of-sale (POS) device including a card stack mechanism having a plurality of card stacks configured to hold a plurality of cards, a card insert-pay mechanism configured to insert one of the plurality of cards into the POS device to be tested, a card swipe-pay mechanism configured to swipe one of the plurality of cards into the POS device to be tested, and a card screen pin-pad mechanism configured to select a key on a keypad or an operation displayed on a display of the POS device associated with one of the card insert-pay mechanism or the card swipe-pay mechanism.
a card holder configured to submit a payment card to the user interface of a tested machine, and Masanam para. 6 teaches in an exemplary embodiment, a system for testing a point-of-sale (POS) device including a card stack mechanism having a plurality of card stacks configured to hold a plurality of cards, a card insert-pay mechanism configured to insert one of the plurality of cards into the POS device to be tested, a card swipe-pay mechanism configured to swipe one of the plurality of cards into the POS device to be tested, and a card screen pin-pad mechanism configured to select a key on a keypad or an operation displayed on a display of the POS device associated with one of the card insert-pay mechanism or the card swipe-pay mechanism.
Masanam does not teach a sensor configured to collect output data by measuring outputs from the user interface of the tested machine in response to submission of the payment card; However, Somani para. 41 teaches Additionally, or alternatively, a configuration parameter may specify a manner in which test robot 220 is to monitor feedback from card reader device 240 (e.g., after fare card 230 is brought within communicative proximity of card reader device 240). For example, once fare card 230 is brought within communicate proximity of card reader device 240, card reader device 240 may provide haptic feedback (e.g., may open a turnstile, may prevent a turnstile from opening, may open a door, may prevent a door from opening, etc.), may emit audible feedback (e.g., a beep, a voice instruction, etc.), may emit visual feedback (e.g., a green light to indicate a successful interaction with fare card 230, a red light to indicate a failed interaction with fare card 230, a message displayed on a digital display, etc.), may transmit a communication (e.g., a near-field communication), or the like. Test robot 220 may monitor one or more such feedback in a manner indicated by a configuration parameter. Further, para. 24 teaches test robot 220 (sometimes referred to herein as a T-Bot) may include one or more devices capable of receiving, generating, storing, processing, analyzing, and/or providing information associated with testing an automated fare management system. For example, test robot 220 may include a robot. In some implementations, test robot 220 may include, for example, a processor for processing instructions (e.g., for executing a test scenario), a fare card reader to read card information from fare card 230, a fare card writer to write information to fare card 230, one or more actuators to move fare card 230 into a communicative proximity of card reader device 240 (e.g., an actuator arm, a robotic arm, a piston, a motor, etc.), one or more sensors to detect feedback from card reader device 240 (e.g., a light sensor, an audio sensor, a haptic sensor, an image processing component, a microphone, etc.), a display component to display information (e.g., card information), a communication interface (e.g., Wi-Fi, Bluetooth, Ethernet, etc.) to communicate with other devices (e.g., test management device 210, card reader device 240, a back office server device, etc.), or the like. Both Masanam and Somani are directed to performing tested on equipment. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Masanam to include a sensor configured to collect output data by measuring outputs from the user interface of the tested machine in response to submission of the payment card as taught by Somani to assist in automating the testing of automated fare management systems, which may reduce the amount of time required to perform the tests and may increase the accuracy of test results (see para. 17).
Masanam in view of Somani does not teach a computing device hosting a machine learning model, wherein the testing rig is configured to send the output data collected by the testing rig to the machine learning model and.
the machine learning model is configured to develop testing protocols to reproduce failure states identified in the output data acquired by the testing rig However, Rivoir para. 61-64 teaches ATE 220 or controller 270 may use machine learning or AI modules trained with the collected test result data and system level test results. The machine learning module may analyze the collected test result data 280 and the system level test result and may predict system level test results based on a new set of collected test data 280. The AI module may further be trained by measured result data without specification limits, such as on-chip sensor data or by test parameters outside specification limits, such as too low voltages or relatively high frequencies to identify system level test fails from the test results. Failing test steps or test activities outside specification limits is not necessarily evidence of bad DUTs.
According to some embodiments, machine learning modules or models predict system level test results from test step or test activity result, including measured results that are beyond specification limits, test steps or scenarios with out-of-specification test parameters and test steps, or scenarios related properties, such as properties of test activities and test resources. This approach may catch some otherwise unidentified SLT fails, but may also fail some DUTs that pass SLT and pass all other legitimate OCST tests. These cases may be considered yield loss through test and may be traded carefully against additionally found SLT fails, preferably based on a cost model. Only those additional test steps or scenarios may be included in production steps that are needed by such models. Other additional test steps can be removed again.
The ATE 220 or the controller 270 may further configured to debug and/or diagnose the DUT. As the test result table 280 includes results 288 of concurrently executed test activities 212 of test scenarios 262, there is a need for further analyses of the collected test data 280 in order to identify and/or classify faulty DUTs or DUT resources. One object of debugging or diagnosing is to identify those test parameters 216 that influence the occurrence of OCST fails most. Test parameters 216, associated with test activities 212 that involve certain actions in specific IP blocks, can provide informative information for debugging.
A machine learning module trained by a table combining test steps or scenarios with test activities, DUT resources, test parameters, test results and overall OCST result, optionally for multiple DUTs may be used for classifying or identifying faulty DUT resources. The machine learning module or machine learning feature selection algorithm may identify which test activities, test or DUT resources and test results are important to explain OCST results that contribute to the occurrence of OCST fails. The controller, or OCST controller is preferably an on-chip processor along with an optional test operating system, but can also be an OCST card that communicates with the DUT or the ATE workstation to control and carry out testing process 200. For example, the OCST controller may trigger execution of multiple test activities and read-out the pass/fail results and/or measurement results. The test activities may include a combination of optional stress generation and/or optional fault detection. Both Masanam and Rivoir are directed to testing equipment. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Masanam to include a computing device hosting a machine learning model, wherein the testing rig is configured to send the output data collected by the testing rig to the machine learning model and.
the machine learning model is configured to develop testing protocols to reproduce failure states identified in the output data acquired by the testing rig as taught by Rivoir to utilize relatively large numbers of test scenarios and activities including multiple test steps and resources and that prevents test parameters from conflicting or colliding to improve test performance and accuracy (para. 10).
As per claim 22 Masanam teaches the system of claim 21, wherein the testing rig comprises a controller, and the computing device is configured to load instructions onto the controller, the instructions comprising a sequence of interactions to be performed by the testing rig. Masanam para. 60 teaches in some implementations, the controller may be uploaded with a test plan for each test mechanism, i.e., the card insert-pay mechanism 200 or the card swipe-pay mechanism 300. In other implementations, the test plan may include details of all the cards that are to be tested with the POS terminal 50, in a sequence.
As per claim 23 Masanam teaches The system of claim 22, wherein the testing rig is configured to determine whether the tested machine provides expected feedback to actions within the sequence of interactions. However, Somani para. 86 teaches As further shown in FIG. 8, process 800 may include detecting feedback provided by the card reader device (block 840). For example, when test robot 220 moves fare card 230 into communicative proximity of card reader device 240, card reader device 240 may provide detectable feedback. Test robot 220 may monitor card reader device 240 (or an environment in which card reader device 240 is located) for feedback. In some implementations, test robot 220 may monitor for feedback by detecting that an action was performed by card reader device 240, such as emitting a light, emitting a sound, moving an object (e.g., opening a turnstile), changing a message or graphic displayed on a display, etc. Additionally, or alternatively, test robot 220 may monitor for feedback by detecting that an action (e.g., an expected action) was not performed by card reader device 240 (e.g., a light was not emitted, a sound was not emitted, an object was not moved, a turnstile was not opened, a message or graphic was not displayed, etc.). In some implementations, test robot 220 may record the monitored feedback (e.g., as test result information).
Both Masanam and Friedel are directed to testing POS systems. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Masanam to include determine whether the interface provides expected feedback to an action performed by the rig and recording feedback provided by the interface as taught by Friedel to speed up the testing process, reduce the labor costs associated with conducting the tests, assure a higher level of accuracy in the testing process, and free valuable subject matter experts for other important activities (See para. 19).
As per claim 24 Masanam teaches The system of claim 23, wherein the testing rig is configured to retry a first action within the sequence of interactions until an earlier of:(i) reaching a predetermined number of retries, and(ii) determining that the user interface provided expected feedback to the first action, before proceeding to a second action within the sequence of interactions. Masanam para. 62 teaches Referring now to FIG. 14, a flowchart of a method for testing the POS system 10 is illustrated, in accordance with an example embodiment. At step 1401, the controller selects a card from a plurality of cards 20 from either the first card stack 111 or the second card stack 112. By way of example, the controller instructs the first arm 70 to move to the selected card to retrieve the card from the first card stack 111 or the second card stack 112. Once the card is grabbed, the first arm 70 moves back to its starting position to transfer the card to the second arm or the third arm 90. At step 1402, the controller determines whether to choose the card insert-pay mechanism 200 or the card swipe-insert mechanism 300. In step S1403, if the card insert-pay mechanism 200 is selected, the second arm 80 is instructed to grip the card from the first arm and move along the insertion-pay track portion 210 so as to enable the card to be inserted in the microprocessor chip reader 55 of the POS terminal 50. Next, in step S1404, the controller can implement a testing suite to conduct a “fall-back” scenario where the card is inserted and failed to read at least three times due to the chip error (or other failures). If no failure occurs, in step S1405, the controller instructs the input device 450 to engage with the keys/buttons of the keypad 51 to enter commands and complete the transaction. In step S1406, if failure occurs, the controller will revert to the card swipe-pay mechanism 300 for further testing. This enables a system to test individual mechanisms in a modular approach, rather than disrupting the functionalities of the other systems. By way of example, the controller instructs the third arm 90 to grab the card from the first arm 70 move along the insertion-swipe track portion 310 so as to enable the card to be swiped having the magnetic strip with the chip reader 57 of the POS terminal 50. Next, when the card swipe is complete, the controller instructs the input device 450 to engage with the keys/buttons of the keypad 51 to enter commands and complete the transaction (S1405). At the conclusion of the test suite or upon certain predetermined conditions resulting from the testing actions, the controller may instruct the arms to act cooperatively to return the card to the card stack, which may be its original position or a different position within the stack.
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Masanam US 2024/0029525 A1 in view of Somani US 20160034723 A1 and in further view of Zuckerman US 2014/0089077 A1.
As per claim 25 Masanam in view of Somani does not teach The testing assembly of claim 13, wherein the tested machine comprises a cooler. However, Zuckerman paras. 66 teaches A network environment, such as the network environment illustrated in FIG. 6, can connect multiple kiosks 600 positioned in a plurality of publicly accessible areas, such as office buildings, transit terminals, grocery stores, department stores, etc. to the central computer 612. The maintenance of the networked kiosks 600 can then be managed from the back end by the central computer 612. The central computer 612 and/or the server 604, for example, can run routine diagnostic maintenance checks on the kiosks 600 to monitor the temperature within the refrigerated compartments of the kiosks 600, identify mechanical problems (e.g., jams associated with the product delivery systems, malfunctions with a bill or coin acceptor, etc.), and/or glitches in the user interface and display pages. If a problem is detected, a notification can be communicated to the central computer 612 and/or a kiosk technician (e.g., via email) describing the nature of the problem. In certain embodiments, the server 604 and/or the central computer 612 can be configured to identify which technician is responsible for or nearest the kiosk at issue and direct the notification to that technician. This proactive diagnostic monitoring can efficiently and cost-effectively ensure that the food products in the kiosks 600 are stored at proper temperatures and that the kiosks 600 are otherwise operating properly. Both Masanam in view of Somani and Zuckerman are directed to testing POS systems including POS systems on vending machines. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Masanam in view of Somani which are directed to testing a payment processor is communicating with a vending machine to include wherein the tested machine comprises a cooler as taught by Zuckerman to efficiently and cost-effectively ensure that the food products in the kiosks 600 are stored at proper temperatures and that the kiosks 600 are otherwise operating properly (see para. 66).
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 DEIRDRE D HATCHER whose telephone number is (571)270-5321. The examiner can normally be reached Monday-Friday 8-4:30.
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, Brian Epstein can be reached at 571-270-5389. 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.
/DEIRDRE D HATCHER/Primary Examiner, Art Unit 3625
Prosecution Insights