DETAILED ACTION
This action is responsive to the application filed on September 09, 2024.
Claims 1-20 are pending and presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 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.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Drawings
The drawings filed on September 09, 2024 are acceptable for examination purposes.
Information Disclosure Statement
As required by M.P.E.P. 609, the applicant’s submission of the Information Disclosure Statement dated September 9, 2024 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending.
Claim Objections
Claims 9-10 and 18 are objected to because of the following informalities: Claim 9 recites “wherein after the software update is applied to the software running on the quality assurance device, the quality assurance device provides instructions to the computing device of the robotic test system to cause the robotic test system to perform the test.”. Please add “the” as indicated in bold. Appropriate correction is required.
Claim 10 recites “wherein the computing device of the robotic test system provides the result of the test to the quality assurance device, and wherein the quality assurance device uploads the result to a remote storage system accessible by the remote computing system.”. Please add “the” as indicated in bold. Appropriate correction is required.
Claim 18 recites “wherein the quality assurance device receives and uploads the result of the test from the robotic test system to a remote storage system accessible by the computing system, and receiving the result of the test includes: obtaining the result of the test from the remote storage system.”. Please add “the” as indicated in bold. Appropriate correction is required.
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.
Claims 1-10, 12-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Brock et al. (US Pub. No. 2023/0297359, hereinafter Brock) in view of Holmes et al. (US Pat. No. 10,181,120, hereinafter Holmes).
With respect to claim 1, Brock teaches a system comprising: a plurality of hardware devices each running software, wherein at least one of the plurality of hardware devices is a quality assurance device (Brock discloses a plurality of cloud-connected media processing devices (printers 104), e.g., thousands of printers, each executing firmware/software that enables label processing and network communication (Brock paragraphs [0014], [0018], [0030]); at least one device is used as a quality assurance device, in that the update is first deployed to a “canary”/monitored set under developer control in a laboratory and to a testing set of printers (printers 104-3 to 104-20) for evaluation before deployment to the remaining devices (Brock paragraphs [0032], [0035], [0039], [0044])). a remote computing system communicatively coupled to the plurality of hardware devices and configured to perform operations (Brock discloses the server 124 having a processor 132 and communications interface 140, connected to the printers 104 over the network 112 (Brock paragraphs [0016], [0022]–[0023])), the operations including: receiving a software update to the software (the server 124 receives a software update 300 (e.g., a firmware update) for deployment to the printers 104, from a developer computing device (Brock paragraphs [0029]–[0030])). deploying the software update to the quality assurance device, wherein [[the robotic test system performs a test on the one or more operational parameters of the quality assurance device]] after the software update is applied to the software running on the quality assurance device (in the testing phase the server 124 transmits the update 300 with an output command 500 to the QA/testing printer (e.g., printer 104-3), which applies the update and then performs an operational function in response to the output command (generating a label 508 bearing a QR code 504), thereby testing the printing operational parameter after the update is applied (Brock paragraphs [0040]–[0042])). receiving a result of the test (the server 124 receives a confirmation (e.g., request 512 generated when the QR code 504 is scanned, or a confirmation generated by a defined output sequence) indicating the result of the post-update operational test (Brock paragraphs [0041]–[0042])). determining the result meets a deployment threshold (the server 124 determines whether a testing threshold (e.g., three or more confirmations) is met (Brock paragraphs [0033], [0043]), and a promotion threshold (e.g., 65%) set to allow acceleration only when the update is likely to cause few or no operational issues (Brock paragraphs [0033], [0057])) and based on the result meeting the deployment threshold, deploying the software update to at least a subset of the plurality of hardware devices (upon an affirmative threshold determination the server proceeds to the primary deployment phase and transmits the update to a selected subset of printers, and thereafter (upon the promotion condition) to a further subset/the remaining printers (Brock paragraphs [0045], [0055], [0059]–[0061])).
Brock is silent to disclose that the post-update operational-parameter test of the quality assurance device is performed by a robotic test system mechanically coupled to that device, however in an analogous art, Holmes teaches:
a robotic test system communicatively and mechanically coupled to the quality assurance device and configured to test one or more operational parameters of the quality assurance device (Holmes discloses a robotic test system comprising a robotic arm 230, a robot controller 212a, an OCR camera 220a with OCR software 212b, and a test coordinator 211. The robotic test system is communicatively coupled to the quality assurance device, in that the host and its components are coupled to the device under test (a payment terminal) and read its responses/display via the OCR camera and the simulators (Holmes column 3 lines 34-52 column 4 lines 36-48, column 5 lines 4-59, column 6 lines 41-64, column 8 lines 24-27); and it is mechanically coupled to the device, in that the robotic arm 230 picks up and inserts a probe 240 into, and presses the pin pad or touch screen of, the device (Holmes column 8 lines 45-63, column 10 lines 37-53). It is configured to test one or more operational parameters of the device — transaction initiation, probe insertion, pin entry, and acceptance/authorization (Holmes column 6 lines 41-64, column 8 lines 24-27, column 10 lines 21-53).
the robotic test system performs a test on the one or more operational parameters of the quality assurance device (Holmes discloses that the robotic test system performs the test by exercising the device under test and reading its responses, and generates a certification report as the result of the test (Holmes column 4 lines 25-35, column 8 lines 11-23, column 10 lines 21-53). In the combination with Brock, this test is performed after the software update is applied to the quality assurance device (Brock paragraphs [0040]–[0042])).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to incorporate the robotic test system of Holmes (robotic arm 230, robot controller 212a, OCR camera 220a, and test coordinator) as the system that performs the post-update operational-parameter test of the quality assurance (canary/testing) device in the phased deployment process of Brock, such that, after the software update is applied, the operational parameters of the QA device are exercised and verified by the robotic test system before the update is promoted for deployment to the remaining devices. One of ordinary skill would have been motivated to do so because Holmes teaches that such operational verification of a financial transaction device was conventionally performed manually and that a fully automated, robotic verification system streamlines the process and improves the reliability and quality of the hardware verification (Holmes column 2 line 64 – column 3 line 33), and because Brock expressly performs small-scale testing of the update on the canary/testing devices, prior to deployment at scale, specifically to confirm that the update will cause few or no operational issues before broad rollout (Brock paragraphs [0044], [0057]). Substituting Holmes’ automated robotic operational test for Brock’s operator-confirmed operational test is the use of a known technique to improve a similar pre-deployment testing gate in the same way, yielding the predictable result of automated, repeatable hardware verification that gates the fleet-wide deployment, with a reasonable expectation of success. With respect claim 2, Brock teaches the operations further including: receiving a selection of the subset of the plurality of hardware devices and a time for deploying the software update to at least the subset (Brock discloses that the server 124 receives configuration parameters 304 identifying the printers (the subset) to which the update is to be deployed and defining the deployment phases (Brock paragraphs [0029], [0031]–[0032]), and selects a time window (e.g., a future one-hour period) during which the update is deployed to the selected subset (Brock paragraphs [0047], [0055])).
With respect claim 3, Brock teaches wherein deploying the software updateto at least the subset includes: generating [[an application programming interface (API) call]] that includes the selection of the subset, the time, and the software update, wherein the subset of the plurality of hardware devices [[are configured to listen for the API call]] to initiate the deployment (Brock discloses deploying the update to the selected subset, the deployment carrying the selection of the subset, the time, and the software update, and the network-connected printers receiving the transmitted commands to initiate the deployment: the server transmits the update to the selected subset during the selected time window, and control of the printers is effected by transmission of commands over the network 112 to the printers, each printer including a controller and communications interface that receives such commands (Brock paragraphs [0016]–[0017], [0031]–[0032], [0047], [0055]). Brock is silent to disclose that the deployment instruction is generated as an application programming interface (API) call that the subset devices are configured to listen for, however in an analogous art, Holmes teaches:
an application programming interface (API) call that includes the selection of the subset, the time, and the software update (Holmes discloses generating an API call/command that carries the relevant data and sending it to the device; the simulator translates the data into an API format (defined per an API specification) and sends the API commands to the device (Holmes column 3 line 53 – column 4 line 24, column 7 lines 50-67)).
the subset of the plurality of hardware devices are configured to listen for the API call to initiate the deployment (Holmes discloses that the device is configured to receive (listen for) the API commands and returns API responses, acting upon the received API commands (Holmes column 7 lines 50-67, column 9 lines 1-20)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to implement the transmission of Brock’s deployment instruction (which includes the selection of the subset, the time, and the software update) to the subset devices as an API call that the subset devices are configured to listen for to initiate the deployment, as taught by Holmes, because Holmes establishes that generating an API call/command carrying the relevant data and having the device listen for/receive it is a known mechanism for communicating instructions to such a device (Holmes column 4 lines 9-24, column 7 lines 50-67, column 9 lines 1-20); using that known mechanism to carry Brock’s deployment instruction to the network-connected devices that already receive transmitted commands (Brock paragraphs [0016]–[0017]) is the use of a known technique to predictably achieve the deployment Brock already performs, with a reasonable expectation of success. With respect to claim 4, Brock teaches wherein, for each hardware device of the subset, the operations further include: receiving a record indicating the software update has been applied to the software running on the respective hardware device (Brock discloses that, for each selected printer, upon successful application the printer re-establishes a connection and the server updates the corresponding record/status indicator in the repository 152 to indicate that deployment succeeded (Brock paragraphs [0036], [0056])). validating the application of the software update based on the record (Brock discloses that the server validates the application based on those per-device status indicators/records when determining whether the promotion conditions are satisfied (Brock paragraphs [0056]–[0057])) and generating a notification indicating a success of the software update on the respective hardware device (Brock discloses that the server generates notifications regarding the deployment outcome, including automatically notifying the developer device and maintaining a success/failure outcome flag for each device (Brock paragraphs [0036], [0043])). With respect to claim 5, Brock teaches wherein the test on the one or more operational parameters of the quality assurance device is performed to evaluate an impact of the software update on operational behavior across the plurality of hardware devices (Brock discloses that deployment of the update to the monitoring/testing (QA) devices enables small-scale testing of the update prior to deployment at scale, and that the promotion conditions are set to permit acceleration only when the update is likely to cause few or no operational issues with the printers, i.e., the test evaluates the impact of the update on operational behavior across the plurality of devices before broad rollout (Brock paragraphs [0044], [0057])). With respect to claim 6, Brock teaches wherein the test on the one or more operational parameters of the quality assurance device is performed to evaluate an impact of the software update on operational behavior across the plurality of hardware devices (Brock discloses media processing devices that are printers 104 configured to generate and print documents (labels bearing indicia) and to dispense them from an outlet 108 (Brock paragraph [0014]); the operational parameter exercised is a function associated with printing documents and generating documents (the QA printer generates and prints a label 508 after applying the update, Brock paragraphs [0040]–[0042]) and with interacting with user devices to initiate or validate a printing session (a client device 120 authenticates with the server and initiates output/print commands, and a client device scans the printed code to validate the operation, Brock paragraphs [0017], [0041])). With respect to claim 7, Brock is silent to disclose, however in an analogous art, Holmes teaches wherein the robotic test system comprises: one or more auxiliary components (Holmes discloses auxiliary components of the robotic test system, namely the robotic arm 230 and the OCR camera 220a (Holmes column 8 lines 24-27, column 8 lines 45-63)) and a computing device communicatively coupled to and configured to control an operation of the one or more auxiliary components to perform the test, wherein the computing device is further communicatively coupled to the quality assurance device (Holmes discloses a computing device (the robot controller 212a / host) communicatively coupled to and configured to control the operation of the auxiliary components to perform the test (controlling the arm’s motion and the camera’s image capture), the computing device being further communicatively coupled to the quality assurance device (Holmes column 3 lines 34-52, column 4 lines 36-48, column 5 lines 3-38, column 6 lines 25-64)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to incorporate the robotic test system of Holmes (robotic arm 230, robot controller 212a, OCR camera 220a, and test coordinator) as the system that performs the post-update operational-parameter test of the quality assurance (canary/testing) device in the phased deployment process of Brock, such that, after the software update is applied, the operational parameters of the QA device are exercised and verified by the robotic test system before the update is promoted for deployment to the remaining devices. One of ordinary skill would have been motivated to do so because Holmes teaches that such operational verification of a financial transaction device was conventionally performed manually and that a fully automated, robotic verification system streamlines the process and improves the reliability and quality of the hardware verification (Holmes column 2 line 64 – column 3 line 33), and because Brock expressly performs small-scale testing of the update on the canary/testing devices, prior to deployment at scale, specifically to confirm that the update will cause few or no operational issues before broad rollout (Brock paragraphs [0044], [0057]). Substituting Holmes’ automated robotic operational test for Brock’s operator-confirmed operational test is the use of a known technique to improve a similar pre-deployment testing gate in the same way, yielding the predictable result of automated, repeatable hardware verification that gates the fleet-wide deployment, with a reasonable expectation of success. With respect to claim 8, Brock teaches wherein the one or more auxiliary components include: a code generation and display device (Brock discloses a code generation and display device that generates and displays a machine-readable code — the QR code 504 — by which the operation of the device is initiated and confirmed (Brock paragraph [0041])). Brock is silent to disclose, however in an analogous art, Holmes teaches: an arm having an end effector (Holmes discloses the robotic arm 230 having an end effector that picks up, holds, manipulates, inserts, and removes the probe 240 with respect to the device under test (Holmes column 8 lines 45-67, column 10 lines 37-53)). a camera (Holmes discloses the OCR camera 220a, which generates images of the device under test (Holmes column 8 lines 24-27)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to incorporate the robotic test system of Holmes (robotic arm 230, robot controller 212a, OCR camera 220a, and test coordinator) as the system that performs the post-update operational-parameter test of the quality assurance (canary/testing) device in the phased deployment process of Brock, such that, after the software update is applied, the operational parameters of the QA device are exercised and verified by the robotic test system before the update is promoted for deployment to the remaining devices. One of ordinary skill would have been motivated to do so because Holmes teaches that such operational verification of a financial transaction device was conventionally performed manually and that a fully automated, robotic verification system streamlines the process and improves the reliability and quality of the hardware verification (Holmes column 2 line 64 – column 3 line 33), and because Brock expressly performs small-scale testing of the update on the canary/testing devices, prior to deployment at scale, specifically to confirm that the update will cause few or no operational issues before broad rollout (Brock paragraphs [0044], [0057]). Substituting Holmes’ automated robotic operational test for Brock’s operator-confirmed operational test is the use of a known technique to improve a similar pre-deployment testing gate in the same way, yielding the predictable result of automated, repeatable hardware verification that gates the fleet-wide deployment, with a reasonable expectation of success. With respect to claim 9, Brock is silent to disclose, however in an analogous art, Holmes teaches wherein after the software update is applied to the software running on the quality assurance device, the quality assurance device provides instructions to the computing device of robotic test system to cause the robotic test system to perform the test (Holmes discloses that the response read from the device under test causes instructions to be provided to the computing device of the robotic test system (the robot controller 212a) to cause the robotic test system to perform the test — the test coordinator requests/instructs the robot controller to initiate the robotic arm to perform an action based on reading a response from the device (Holmes, Abstract; column 5 lines 4-59, column 10 lines 21-36); under the BRI above, the QA device’s response provides instructions that cause the robotic test system’s computing device to perform the test)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to incorporate the robotic test system of Holmes (robotic arm 230, robot controller 212a, OCR camera 220a, and test coordinator) as the system that performs the post-update operational-parameter test of the quality assurance (canary/testing) device in the phased deployment process of Brock, such that, after the software update is applied, the operational parameters of the QA device are exercised and verified by the robotic test system before the update is promoted for deployment to the remaining devices. One of ordinary skill would have been motivated to do so because Holmes teaches that such operational verification of a financial transaction device was conventionally performed manually and that a fully automated, robotic verification system streamlines the process and improves the reliability and quality of the hardware verification (Holmes column 2 line 64 – column 3 line 33), and because Brock expressly performs small-scale testing of the update on the canary/testing devices, prior to deployment at scale, specifically to confirm that the update will cause few or no operational issues before broad rollout (Brock paragraphs [0044], [0057]). Substituting Holmes’ automated robotic operational test for Brock’s operator-confirmed operational test is the use of a known technique to improve a similar pre-deployment testing gate in the same way, yielding the predictable result of automated, repeatable hardware verification that gates the fleet-wide deployment, with a reasonable expectation of success. With respect to claim 10, Brock teaches wherein the quality assurance device uploads the result to a remote storage system accessible by the remote computing system (Brock discloses a remote storage system accessible by the remote computing system (the repository 152 maintained at/accessible by the server 124), to which each device’s record/result is uploaded upon the device re-establishing its connection (Brock paragraphs [0027], [0056])).
Brock is silent to disclose, however in an analogous art, Holmes teaches: wherein the computing device of robotic test system provides the result of the test to the quality assurance device (Holmes discloses that the computing device of the robotic test system generates and provides the result of the test — the OCR/robot components provide their results to the test coordinator, which generates a certification report as the result (Holmes column 4 lines 25-35, column 8 lines 10-23)).
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to.... route the test result generated by the robotic test system of Holmes through the quality assurance device to the remote storage system (repository 152) accessible by the remote computing system of Brock, because such an arrangement is no more than the obvious rearrangement of where the test result is aggregated and stored — Brock already maintains a server-accessible repository of per-device records (Brock paragraphs [0027], [0056]) and Holmes already generates the test result (Holmes column 4 lines 25-35, column 8 lines 10-23) — which performs the same function of making the result available to the deployment-decision logic and yields no new or unexpected result, with a reasonable expectation of success. With respect to claim 12, the claim is directed to a system that corresponds to the system recited in claim 1, respectively (see the rejection of claim 1 above). Claim 12 differs from claim 1 only in that it further recites at least one memory and at least one processor executing the instructions, and recites the robotic test system as electrically and mechanically connected (rather than communicatively and mechanically coupled) to the quality assurance device. These differing limitations are addressed below. Block teaches at least one memory storing instructions (Brock discloses the server 124 including a memory 136 storing computer-readable instructions, including the deployment application 148 (Brock paragraphs [0022], [0025]–[0026])).
at least one processor operatively connected to the at least one memory and configured to execute the instructions to perform operations (Brock discloses a processor 132 interconnected with the memory 136 and executing the stored instructions to perform the deployment operations (Brock paragraphs [0022], [0025]–[0026])). Brock is silent to disclose the robotic test system electrically and mechanically connected to the quality assurance device, however in an analogous art, Holmes teaches a robotic test system electrically and mechanically connected to the quality assurance device performs a test on one or more operational parameters of the quality assurance device (Holmes discloses the robotic test system electrically connected to the quality assurance device (the robot controller/host components electrically/communicatively coupled to the device and to one another, Holmes column 3 lines 34-52, column 14 lines 36-48, column 6 lines 25-40 and mechanically connected to it (the robotic arm 230 mechanically engages the device, Holmes column 8 lines 45-63, column 10 lines 37-53), which performs the test of the device’s operational parameters (Holmes column 6 lines 41-64, column 8 lines 24-17, column 10 lines 21-53)). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to incorporate the robotic test system of Holmes (robotic arm 230, robot controller 212a, OCR camera 220a, and test coordinator) as the system that performs the post-update operational-parameter test of the quality assurance (canary/testing) device in the phased deployment process of Brock, such that, after the software update is applied, the operational parameters of the QA device are exercised and verified by the robotic test system before the update is promoted for deployment to the remaining devices. One of ordinary skill would have been motivated to do so because Holmes teaches that such operational verification of a financial transaction device was conventionally performed manually and that a fully automated, robotic verification system streamlines the process and improves the reliability and quality of the hardware verification (Holmes column 2 line 64 – column 3 line 33), and because Brock expressly performs small-scale testing of the update on the canary/testing devices, prior to deployment at scale, specifically to confirm that the update will cause few or no operational issues before broad rollout (Brock paragraphs [0044], [0057]). Substituting Holmes’ automated robotic operational test for Brock’s operator-confirmed operational test is the use of a known technique to improve a similar pre-deployment testing gate in the same way, yielding the predictable result of automated, repeatable hardware verification that gates the fleet-wide deployment, with a reasonable expectation of success. With respect to claims 13-17, the claims are directed to a system that corresponds to the system recited in claims 2-6, respectively (see the rejection of claims 2-6 above). With respect to claim 18, the claim is directed to a system that corresponds to the system recited in claim 10, respectively (see the rejection of claim 10 above). Claim 18 further recites that receiving the result of the test includes obtaining the result from the remote storage system (Brock discloses that the computing system obtains records (results) from the remote storage system, e.g., via the query 600 to the repository 152 (Brock paragraphs [0027], [0048], [0056])).
With respect to claim 20, the claim is directed to a method that corresponds to the system recited in claim 1, respectively (see the rejection of claim 1 above). Claim 20 differs from claim 1 in reciting the robotic test system as electrically and mechanically connected (rather than communicatively and mechanically coupled), and in further reciting denying deployment of the update to any of the hardware devices when the result fails to meet the deployment threshold. These differing limitations are addressed below. Block teaches when the result fails to meet the deployment threshold, denying a deployment of the software update to any of the plurality of hardware devices (Brock discloses that, when the testing threshold is not met, the server does not proceed to deploy to the population and may abort performance of the method, and when a failure threshold is reached the deployment is terminated; deployment to any of the devices is thereby denied (Brock paragraphs [0043], [0058])). Brock is silent to disclose the robotic test system electrically and mechanically connected to the quality assurance device, however in an analogous art, Holmes teaches a robotic test system electrically and mechanically connected to the quality assurance device performs a test on one or more operational parameters of the quality assurance device (Holmes discloses the robotic test system electrically connected to the quality assurance device (the robot controller/host components electrically/communicatively coupled to the device and to one another, Holmes column 3 lines 34-52, column 14 lines 36-48, column 6 lines 25-40 and mechanically connected to it (the robotic arm 230 mechanically engages the device, Holmes column 8 lines 45-63, column 10 lines 37-53), which performs the test of the device’s operational parameters (Holmes column 6 lines 41-64, column 8 lines 24-17, column 10 lines 21-53)). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to incorporate the robotic test system of Holmes (robotic arm 230, robot controller 212a, OCR camera 220a, and test coordinator) as the system that performs the post-update operational-parameter test of the quality assurance (canary/testing) device in the phased deployment process of Brock, such that, after the software update is applied, the operational parameters of the QA device are exercised and verified by the robotic test system before the update is promoted for deployment to the remaining devices. One of ordinary skill would have been motivated to do so because Holmes teaches that such operational verification of a financial transaction device was conventionally performed manually and that a fully automated, robotic verification system streamlines the process and improves the reliability and quality of the hardware verification (Holmes column 2 line 64 – column 3 line 33), and because Brock expressly performs small-scale testing of the update on the canary/testing devices, prior to deployment at scale, specifically to confirm that the update will cause few or no operational issues before broad rollout (Brock paragraphs [0044], [0057]). Substituting Holmes’ automated robotic operational test for Brock’s operator-confirmed operational test is the use of a known technique to improve a similar pre-deployment testing gate in the same way, yielding the predictable result of automated, repeatable hardware verification that gates the fleet-wide deployment, with a reasonable expectation of success.
Claims 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Brock et al. (US Pub. No. 2023/0297359, hereinafter Brock) in view of Holmes et al. (US Pat. No. 10,181,120, hereinafter Holmes) and further in view of Johnson et al. (US Pub. No. 2022/0164171, hereinafter Johnson). With respect to claim 11, Brock teaches wherein receiving the software update includes: receiving new code associated with the software (Brock discloses receiving new code associated with the software — the software/firmware update received at the server 124 from a developer computing device, the firmware being software tailored to the device that is periodically updated (Brock paragraphs [0018]–[0019], [0029])).
Brock in view of Holmes is silent to disclose, however in an analogous art, Johnson teaches: building an artifact for the software update based on the new code (Johnson discloses a continuous-integration build pipeline that receives source code (new code) from a source code repository and builds a deployment artifact based on the new code by compiling the source code into executable files and packaging the executable files into the deployment artifact (e.g., a binary file or compressed archive) (Johnson paragraphs [0002], [0019], [0025], [0033], [0040])). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to build an artifact for Brock/Holmes software update from the received new code, as taught by Johnson, by compiling the new code into executable files and packaging them into a deployment artifact (Johnson paragraphs [0025], [0033], [0040]), because Johnson teaches that a continuous-integration build pipeline that compiles source code and generates a deployment artifact is a known and advantageous way to prepare code for deployment to a target runtime environment (Johnson paragraphs [0002], [0019]); applying Johnson’s build-pipeline artifact generation to Brock’s received update is the use of a known technique to predictably produce a deployable form of the update suitable for transmission to and installation on the devices, with a reasonable expectation of success.
With respect to claim 19, the claim is directed to a system that corresponds to the system recited in claim 11, respectively (see the rejection of claim 11 above).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Render et al. (US Pub. No. 2025/0211489) Systems, devices, and methods for deployment of software applications on a cloud platform are provided. An example method includes receiving in the cloud-agnostic CI/CD system an artifact associated with an application to be deployed on a target cloud platform from a service vendor, extracting configuration parameters specific to the target cloud platform of the application from the artifact, selecting a predetermined cloud-agnostic configuration template containing standardized configuration parameters, mapping the cloud-specific configuration parameters to the standardized configuration parameters, determining a reference configuration setting based on the cloud-agnostic configuration template, storing by the reference configuration determination device the reference configuration setting in a repository as a single source of truth, applying the reference configuration setting to the cloud-agnostic configuration template to generate an initial deployment script, and executing the initial deployment script to deploy the application on the target cloud platform. (see abstract).
Singh (US Pub. No. 2024/0168868) A solution for optimizing the deployment of applications in a cloud-based environment is provided. A method for optimizing the deployment of applications in a cloud-based environment is disclosed. The method is implemented by at least one processor. The method includes receiving at least one user artifacts file for direct deployment on a test environment. Next, the method includes deploying the at least one user artifacts file onto the test environment. Next, the method includes performing a set of testing events on artifacts included in the at least one user artifacts file. Thereafter, the method includes transmitting the at least one user artifacts file for pipeline deployment based on a successful result of the testing events (see abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 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, Hyung S Sough can be reached at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
