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 .
Claims 1-15 are pending in this office action.
Claim 1 is amended.
Response to Arguments
Applicant’s arguments filled 08/12/2025 with respect to claims 1-15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Spittle et al a new art discloses a system where the code is developed and tested before deployment. Among the functionalities that are tested are user action: such as increasing/decreasing volume , play music and skipping to next track. Also disclosed is a charging box for earbud that may be used to trigger certain testing and simulation.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
Claims
Place holders
functions
1
host server
Review, obtain, compile, actuate
2, 4, 6, 8, 10
Host server
determine
3, 5, 7
Host server
send
9
Host server
mark
11
Host server
merge
13
Slave server
send
15
Host server
Send, mark, merge
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 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.
Claims 1-4, 9-12 are rejected under 35 U.S.C. 103 as being unpatentable Jalal et al US20230305813A1 in view of Kolesnik et al US20160239295A1 and Spittle et al US20230300532A1.
As per claim Jalal discloses an automated integration and test system :
[0005]“receiving, at a continuous integration continuous deployment (CI/CD) system, source code from a software development system”;
comprising:
a plurality of working stations:
[0082] “At step 430, a second pipeline of tools is configured for performing the code analysis in accordance with the second QMS. The code analysis includes dynamic analysis. The configuring the second pipeline of tools includes: (i) identifying a set of dynamic analysis tools that is capable of analyzing the source code to satisfy the second set of requirements, (ii) determining a dynamic testing protocol to execute the set of dynamic analysis tools to satisfy the second set of requirements, and (iii) provisioning the set of dynamic analysis tools within the second pipeline of tools in accordance with the dynamic testing protocol”;
and a host server configured to execute: reviewing a submitted code so as to obtain a review result:
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0005] to review code result.
Jalal discloses a code review system 235 executed by a processor in CI/CD pipeline[0054] that uses static analysis for reviewing code result
Examiner interpretation:
[0054] “The code review system 235 then performs code verification in accordance with the optimal set of code review tasks. The optimal set of code review tasks define a series of tests to be run against the source code. The code review system 235 includes static analysis tools that perform the series of tests to analyze the source code. The code review system 235 determines compliance or noncompliance of the source code with the set of requirements based on results of the series of tests run against the source code.”;
compiling the submitted code so as to obtain a compiling result in response to that the review result indicates "pass":
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0005] to review code result outcome.
Jalal discloses a code review system 235 executed by a processor in CI/CD pipeline[0054] that uses static analysis for reviewing code result outcome: valid: ”Pass”
Examiner interpretation:
[0054]“Thereafter, the code review system 235 determines validity of the source code based on the compliance or noncompliance of the source code with the set of requirements. Upon compliance and/or validation of the source code, the code hosting platform 230 releases the source code to the CD component 215 for code building and further testing (e.g., static analysis, dynamic analysis, and/or white sourcing).
obtaining a complied code ,wherein the complied code comprises an item to be tested, and the item to be tested is at least one selected from the group consisting of a modular test and a functional test:
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0005] to receive compiled code.
Jalal discloses a system of CI/CD executed by a processor in CI/CD pipeline[0071] and [0084] to receive code for functional and modular testing
Examiner interpretation:
[0071]“The intended use requirement evaluates whether the overall functionality of the various features is performing as intended to implement the overall intended use of the source code or software (e.g., image processing for tumor detection). The international, national, and/or regional regulation requirements evaluate whether government regulations (e.g., national security, cybersecurity, software malfunction, data privacy, etc.) specific to the software platform are being satisfied”;
and actuating at least one of the working stations to execute the item to be tested so as to obtain a full test result:
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0005] actuate a working station for testing code.
Jalal discloses a system of CI/CD executed by a processor in CI/CD pipeline[0061] to receive code and execute functional and modular testing in a container of the cloud.
Examiner interpretation:
[0061] “The source code will be fetched and any artifacts thereof from a repository, the code will be compiled with a check for dependencies, automated tests will be run to confirm operability, the files, libraries, and code will be respectively linked, upon successful testing, artifacts representative of the executable program will be finalized and stored, and build logs will be recorded”;
[0062] At step 315, the CI of the software development system tests and validates the source code and executable program in accordance with QMS of the software development system. For example, each software development system may establish a software life cycle model for validating their software that has been developed within the framework of a QMS that is appropriate for the release manager’s product and organization.
But not explicitly:
obtaining a compiled code in response to that the compiling result indicates "success,"
wherein: the item to be tested comprises a user operation test, and the user operation test comprises at least one selected from the group consisting of: opening a lid of a charging box, closing the lid of the charging box, taking Bluetooth earbuds out of the charging box, putting the Bluetooth earbuds in the charging box, increasing a volume, decreasing the volume, playing a previous track, and playing a next track:
and the full test result comprises at least one selected from the group consisting of: an audio playback, an audio synchronization, and an amplitude of current.
Kolesnik discloses:
obtaining a compiled code in response to that the compiling result indicates "success,"
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0005] to receive successfully compiled code.
Kolesnik discloses a CI system 140 executed by system 400 of fig. 4 to receive a code and process the code compilation.(success compilation).
Examiner interpretation:
[0022]“ The CI system 140 may compile the first code change and/or other source code related to the first code change. The CI system 140 may also perform one or more tests on the code changes, such as one or more-unit tests, integration tests, etc. In some implementations, upon successfully compiling the first code change and/or determining that the first code change passes the tests, the CI system 140 may generate a message indicating that the first code change is approved by the CI system 140 and may send the message to the code review system 130.”;
[0031] “The build component 151 may determine whether the first source code passes all of the tests. In response to determining that the first source code passes all of the tests, the build component 151 may deploy the first source code to the production environment.”;
wherein: the item to be tested comprises a user operation test:
[0037]“The build component 151 may then emulate one or more user actions to test whether the application can perform one or more desired functions, whether the application can output a desired output, etc.
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Kolesnik into teachings of Jalal to make a code change to source code of an application stored in a source code repository hosted by a revision control system. The code change may then be merged into the source code of the application stored in the source code repository. Prior to the code change being merged into the application, it would be desirable to perform various tests on the code change to ensure that the application can work as designed when the code change is integrated with the application. [Kolesnik 0002].
But not explicitly:
and the user operation test comprises at least one selected from the group consisting of: opening a lid of a charging box, closing the lid of the charging box, taking Bluetooth earbuds out of the charging box, putting the Bluetooth earbuds in the charging box, increasing a volume, decreasing the volume, playing a previous track, and playing a next track:
and the full test result comprises at least one selected from the group consisting of: an audio playback, an audio synchronization, and an amplitude of current.
Spittle discloses:
and the user operation test comprises at least one selected from the group consisting of: opening a lid of a charging box, closing the lid of the charging box, taking Bluetooth earbuds out of the charging box, putting the Bluetooth earbuds in the charging box, increasing a volume, decreasing the volume, playing a previous track, and playing a next track:
[0870] “The movements may be translated into specific commands to control the functions of the audio system. In some scenarios, gestures are a preferred form of UI since they do not require the user to touch the ear pieces or an electronic device and they do not require the user to make a sound. Exemplary gestures may include, but are not limited to, waving the user’s left hand near the left ear piece to skip to the next track when streaming music, moving the user’s right hand upwards near the right ear piece to increase volume, and moving the user’s hand downwards to decrease volume.
[0597] Additionally, when the earbuds are placed in the charging pod, software and acoustic devices run inside it, such as microphones and speakers, so the earbuds can be calibrated and tested 3813 while inside the pod. For example, the user may test the functionality of the speakers or microphone or whether the device needs to be cleaned of earwax. Any problems that are detected are shown on the user interface, so that appropriate actions are taken such as recalibrating or sending the unit back to the manufacturer.
and the full test result comprises at least one selected from the group consisting of: an audio playback, an audio synchronization, and an amplitude of current.
[0891]“The internal speakers are used for calibration functions of the ear devices. The external speakers are used as notification and music playback speakers so that the charging pod can provide audio streaming when the ear pods are being charged. “;
[0667]“For example, if the user is adjusting the amplitude of the sound signals, the audio system may synchronize the gain changes and apply them to the sound signals to each ear piece at the same time. That is, the audio system may synchronize adjustments made to the sound signals. The synchronization may involve applying the adjustments simultaneously, with a certain delay between different sound signals, etc. In some embodiments, the audio system may be programmed to apply parameter adjustments and programmed information to binaural audio data streams simultaneously.
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Spittle into teachings of Jalal and Kolesnik to allow the user to control more than just the sound levels and to select more than one of a pre-determined settings. The system optimizes the processing efficiency of the audio systems to facilitate more advanced customization of audio processing. Furthermore, to allow for the coexistence and/or cooperation of various components that allow for more specialized and end-user-specific customization. And finally, to allow manufacturers including the developers to configure and test various different parameters, settings, algorithms, functions, processes, processes and accessories. The platform allows the manufacturer to simulate the performances from possible options for the audio system, and then load the selected option from the development platform to the system, thus enabling the end user to have the same level of control and ability to access and upload.[Spittle 0010].
As per claim 2, the rejection of claim 1 is incorporated and furthermore Jalal discloses:
wherein the host server determines that the full test result indicates "not pass" in response to that at least one of the functional test and the modular test does not pass a testing.
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0007] to determine passing/failed test case.
Jalal discloses a system of CI/CD executed by a processor in CI/CD pipeline[0071] to determine[0063] if all or at least one of the test is/are failed.
Examiner interpretation:
[0063] “At step 325, a determination is made as to whether the source code and executable program are valid and/or are of sufficient quality. If the source code and executable program are invalid (do not meet all or a portion of the requirements of the QMS) and/or the source code and executable program are of poor quality (as defined and measured by the software development system in accordance with the QMS), then the CI of the software development system forwards the source code back to the development team to fix the failures and/or quality of the source code”;
See also kolesnik [0032 and 0046]
As per claim 3, the rejection of claim 1 is incorporated and furthermore Jalal discloses:
wherein the host server is further configured to execute: sending the review result to a code source end in response to that the review result indicates "not pass":
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0006] to send review result.
Jalal discloses a system of CI/CD executed by a processor in CI/CD pipeline[0071] to determine[0074] to forward the result(invalid = ”not pass”).
Examiner interpretation:
[0074]“At step 340, a determination is made as to whether the source code and executable program are valid and/or include vulnerabilities due to open-source components. If the source code and executable program are invalid (do not meet all or a portion of the requirements of the QMS) and/or the source code and executable program include vulnerabilities due to open-source components (as defined and determined by the software platform in accordance with the QMS), then the CI/CD system forwards the source code back to the development team to fix the failures and/or vulnerabilities of the source code”;
As per claim 4, the rejection of claim 3 is incorporated and furthermore Jalal discloses:
wherein the host server determines that the full test result indicates "not pass" in response to that at least one of the functional test and the modular test does not pass a testing:
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0007] determine success/failure of the test.
Jalal discloses a system of CI/CD executed by a processor in CI/CD pipeline[0071] to determine[0069] outcome of testing: if at least one test failed..
Examiner interpretation:
[0069]“ In some instances, the quality and compliance or noncompliance determination is an all or nothing determination, e.g., the source code must meet all requirements to be considered to have adequate quality and compliance.
…
In contrast, if the different analysis techniques demonstrate that the source code does not have adequate quality and compliance, then a notification may be sent to the actor and/or administrators of the software platform. The notification identifies the source code and the reasons for the failed verification. The execution of the test plan and results of the verification are recorded in a manner to maintain traceability between feature requirements, test plan for the feature requirements, and evidence supporting the test plan was executed. The record will be maintained in a repository for future use, e.g., to support government regulatory review.”;
See also kolesnik [0032 and 0046]
As per claim 9, the rejection of claim 1 is incorporated and furthermore Jalal does not explicitly disclose:
wherein the host server is further configured to execute: marking the submitted code as "can be merged" in response to that the full test result indicates "pass".
Kolesnik discloses:
wherein the host server is further configured to execute: marking the submitted code as "can be merged" in response to that the full test result indicates "pass".
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0015] to determine passing and code merging.
Kolesnik discloses a CI of the software development system executed by system 400 of fig. 4 to indicate [0024] that the code is ready for merging based on success testing
[0024] “The source code review system 130 may rank the given code change in view of input from the client devices 110a-z, the CI system 140, and/or the deployment system 150. For example, the source code review system 130 may rank the code change as “ready to be merged” in response to receiving input indicating that the reviewers have approved the code change and/or that the code change passes one or more tests executed by the CI system 140 and/or the deployment system 150”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Kolesnik into teachings of Jalal to make a code change to source code of an application stored in a source code repository hosted by a revision control system. The code change may then be merged into the source code of the application stored in the source code repository. Prior to the code change being merged into the application, it would be desirable to perform various tests on the code change to ensure that the application can work as designed when the code change is integrated with the application. [Kolesnik 0002].
As per claim 10, the rejection of claim 9 is incorporated and furthermore Jalal discloses:
wherein the host server determines that the full test result indicates "not pass" in response to that at least one of the functional test and the modular test does not pass a testing:
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0007] to determine passing/failed test case.
Jalal discloses a system of CI/CD executed by a processor in CI/CD pipeline[0071] to determine[0082, 0085] if all or at least one of the test is/are failed.
Examiner interpretation:
[0069]“ In some instances, the quality and compliance or noncompliance determination is an all or nothing determination, e.g., the source code must meet all requirements to be considered to have adequate quality and compliance.
…
In contrast, if the different analysis techniques demonstrate that the source code does not have adequate quality and compliance, then a notification may be sent to the actor and/or administrators of the software platform. The notification identifies the source code and the reasons for the failed verification. The execution of the test plan and results of the verification are recorded in a manner to maintain traceability between feature requirements, test plan for the feature requirements, and evidence supporting the test plan was executed. The record will be maintained in a repository for future use, e.g., to support government regulatory review.”;
See also kolesnik [0032 and 0046]
As per claim 11, the rejection of claim 1 is incorporated and furthermore Jalal does not explicitly disclose:
wherein the host server is further configured to execute: merging the submitted code into a full code in response to that the full test result indicates "pass".
Kolensik discloses:
wherein the host server is further configured to execute: merging the submitted code into a full code in response to that the full test result indicates "pass".
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0006] to determine passing/failed test case.
Kolesnik discloses a CI of the software development system executed by system 400 of fig. 4 to indicate [0031] that the code can be merged based on success testing
Examiner interpretation:
[0031] “The build component 151 may determine whether the first source code passes all of the tests. In response to determining that the first source code passes all of the tests, the build component 151 may deploy the first source code to the production environment.”;
[0024] “The source code review system 130 may rank the given code change in view of input from the client devices 110a-z, the CI system 140, and/or the deployment system 150. For example, the source code review system 130 may rank the code change as “ready to be merged” in response to receiving input indicating that the reviewers have approved the code change and/or that the code change passes one or more tests executed by the CI system 140 and/or the deployment system 150. The source code review system 130 may then send, to a client device of the user, a request to merge the code change into the remote repository 121.
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Kolesnik into teachings of Jalal and Spittle to make a code change to source code of an application stored in a source code repository hosted by a revision control system. The code change may then be merged into the source code of the application stored in the source code repository. Prior to the code change being merged into the application, it would be desirable to perform various tests on the code change to ensure that the application can work as designed when the code change is integrated with the application. [Kolesnik 0002].
As per claim 12, the rejection of claim 11 is incorporated and furthermore Jalal discloses:
wherein the host server determines that the full test result indicates "not pass" in response to that at least one of the functional test and the modular test does not pass a testing.
[0069]“ In some instances, the quality and compliance or noncompliance determination is an all or nothing determination, e.g., the source code must meet all requirements to be considered to have adequate quality and compliance.
…
In contrast, if the different analysis techniques demonstrate that the source code does not have adequate quality and compliance, then a notification may be sent to the actor and/or administrators of the software platform. The notification identifies the source code and the reasons for the failed verification. The execution of the test plan and results of the verification are recorded in a manner to maintain traceability between feature requirements, test plan for the feature requirements, and evidence supporting the test plan was executed. The record will be maintained in a repository for future use, e.g., to support government regulatory review.”;
See also kolesnik [0032 and 0046]
Claims 5-8 are rejected under 35 U.S.C. 103 as being unpatentable Jalal et al US20230305813A1 in view of Kolesnik et al US20160239295A1, Spittle et al US20230300532A1 and Jones et al US20200218634A1.
As per claim 5, the rejection of claim 3 is incorporated and furthermore Jalal discloses:
wherein the host server is further configured to execute: sending the compiling result to the code source end in response to that the compiling result indicates "not success".
Jones discloses:
wherein the host server is further configured to execute: sending the compiling result to the code source end in response to that the compiling result indicates "not success".
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0003] determine success/failure of compilation.
Jones discloses a system of fig. 13 executing a process of fig 10and [0084] to determine the compiling result and update the output accordingly.
Examiner interpretation:
[0084] Example process 1000 continues at step 1004 with receiving, via the computer network, a compiling error identified, for example, at compile-time by the cloud compiler 232”;
[0089] “In the example screen 1100a depicted in FIG. 11A, the error reporting element 1106 is displaying an indication that one error has been identified. Specifically, the identified error is a type error due to an improper conversion from an integer value to a string value in the loaded classes. As shown in FIG. 1A, the indication of the error may include a textual description of the error, but alternatively or in addition may include other such indicating elements such as a graphical indication of the error, etc. Further, the file explorer element 1102 may be updated to reflect identified errors in one or more of the files associated with a given project”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Jones into teachings of Jalal and Kolesnik and Spittle to evaluate code before deployment. code evaluation reduces delays due to deployment failure, provides more stable response times, and enables customized and complex analysis such as a whole code-base error reporting. [Jones 0019].
As per claim 6, the rejection of claim 5 is incorporated and furthermore Jalal discloses:
wherein the host server determines that the full test result indicates "not pass" in response to that at least one of the functional test and the modular test does not pass a testing :
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0007] to determine passing/failed test case.
Jalal discloses a system of CI/CD executed by a processor in CI/CD pipeline[0071] to determine[0063, 0069] if all or at least one of the test is/are failed.
Examiner interpretation:
[0069]“ In some instances, the quality and compliance or noncompliance determination is an all or nothing determination, e.g., the source code must meet all requirements to be considered to have adequate quality and compliance.
…
In contrast, if the different analysis techniques demonstrate that the source code does not have adequate quality and compliance, then a notification may be sent to the actor and/or administrators of the software platform. The notification identifies the source code and the reasons for the failed verification. The execution of the test plan and results of the verification are recorded in a manner to maintain traceability between feature requirements, test plan for the feature requirements, and evidence supporting the test plan was executed. The record will be maintained in a repository for future use, e.g., to support government regulatory review.”;
See also kolesnik [0032 and 0046]
As per claim 7, the rejection of claim 5 is incorporated and furthermore Jalal discloses:
wherein the host server is further configured to execute: sending the full test result to the code source end in response to that the full test result indicates "not pass":
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0007] to determine passing/failed test case.
Jalal discloses a system of CI/CD executed by a processor in CI/CD pipeline[0071] to determine[0063, 0069] if all or at least one of the test is/are failed.
Examiner interpretation:
[0069]“ In some instances, the quality and compliance or noncompliance determination is an all or nothing determination, e.g., the source code must meet all requirements to be considered to have adequate quality and compliance.
…
In contrast, if the different analysis techniques demonstrate that the source code does not have adequate quality and compliance, then a notification may be sent to the actor and/or administrators of the software platform. The notification identifies the source code and the reasons for the failed verification. The execution of the test plan and results of the verification are recorded in a manner to maintain traceability between feature requirements, test plan for the feature requirements, and evidence supporting the test plan was executed. The record will be maintained in a repository for future use, e.g., to support government regulatory review.”;
As per claim 8, the rejection of claim 7 is incorporated and furthermore Jalal discloses:
wherein the host server determines that the full test result indicates "not pass" in response to that at least one of the functional test and the modular test does not pass a testing:
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0007] to determine passing/failed test case.
Jalal discloses a system of CI/CD executed by a processor in CI/CD pipeline[0071] to determine[0082, 0085] if all or at least one of the test is/are failed.
Examiner interpretation:
[0082] “The dynamic testing protocol includes initially executing the code or executable program in run time, and based on the execution, performing one or more of the following: functional testing, testing for critical functions, testing for function of specific features, testing for compatibility and integration with other systems and/or localization, and regression analysis. Thereafter, the dynamic testing includes performing one or more of the following: performance testing, load and stress testing, and volume and endurance testing.”;
[0085] At step 440, upon invalidation of the source code, a notification of the invalidity is provided to the software development system. The notification can include information concerning one or more reasons for the invalidation.
See also kolesnik [0032 and 0046]
Claims 13-14 are rejected under 35 U.S.C. 103 as being unpatentable Jalal et al US20230305813A1 in view of Kolesnik et al US20160239295A1, Spittle et al US20230300532A1 and LUO et al WO2019090454A1.
As per claim 13 the rejection of claim 1 is incorporated and furthermore Jalal does not explicitly disclose:
wherein each of the working stations comprises a slave server and a development board, and the slave server is configured to execute: sending a test command to the development board according to the compiled code so that the development board generates a response;
wherein the test command is at least one selected from the group consisting of a first control command and a second control command; and
wherein the host server obtains the full test result according to the response of the development board.
Luo discloses:
wherein each of the working stations comprises a slave server and a development board, and the slave server is configured to execute: sending a test command to the development board according to the compiled code so that the development board generates a response;
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0017] to submit test command.
Luo discloses PC202 to send test command and collect test result page 6 3rd paragraph;
Examiner interpretation:
page 6 3rd paragraph:“The PC 202 stores the code to be tested, for example, the protocol stack code of the Bluetooth protocol, and the form may be source code or a compiled BIN file or other executable file. The PC 202 burns the BIN file or other executable file onto the BLE FPGA development board 206 prior to the Bluetooth test. Moreover,the PC 202 collects the test logs sent by the mobile terminal 204 and the BLE FPGA development board 206, analyzes the test logs, and outputs the test results in an appropriate form, such as outputting a test report.)”
wherein the test command is at least one selected from the group consisting of a first control command and a second control command:
page 6 6th paragraph:”The BLE FPGA development board 206 is used to place the BLE to be tested, which accepts commands from the mobile terminal 204 and the PC 202, and performs Bluetooth testing based on the test cases.”;
page 7 7th paragraph :Step S302: The test control device sends a test control command to the peer device, instructing the peer device to use the pre-stored test case to perform test interaction with the second Bluetooth device to be tested by the second Bluetooth device in the peer device.”
wherein the host server obtains the full test result according to the response of the development board.
Page 8 4th paragraph:”In a feasible solution, the peer device and the FPGA development board can send to the test control device. The test log carries the test interaction information in the test log, and the test control device respectively receives the test log sent by the peer device and the FPGA development board, determines the Bluetooth test result of the first Bluetooth device according to the test log, and outputs the Bluetooth test result. However, it is not limited to the form of the test log, and any other suitable way of obtaining the information of the test interaction can be applied.”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Luo into teachings of Jalal and Kolesnik and Spittle for an efficient testing of Bluetooth devices including basic function and compatibility tests. Using different testing platform, the server can integrate any devices resulting in efficient Bluetooth test, versatility and scalability of the test platform [LUO page 2 first paragraph].
As per claim 14 the rejection of claim 13 is incorporated and furthermore Jalal does not explicitly disclose:
wherein each of the working stations further comprises a control board and at least one test sensing device, the second control command is sent to the development board through the control board, the test sensing device sends the response of the development board to the slave server, and the automated integration and test system is used for functional testing of a Bluetooth product
Luo discloses:
wherein each of the working stations further comprises a control board and at least one test sensing device, the second control command is sent to the development board through the control board, the test sensing device sends the response of the development board to the slave server:
Page 8 5th paragraph “In this embodiment, the Bluetooth test of the Bluetooth device to be tested is implemented by using the test control device, the Bluetooth device to be tested, and the peer device corresponding to the Bluetooth device to be tested, wherein the test control device controls the Bluetooth device to be tested and the peer device, A test case is stored in the end device. After receiving the test control command of the test control device, the peer device performs a test interaction with the Bluetooth device to be tested, thereby implementing a Bluetooth test of the Bluetooth device to be tested. “;
and the automated integration and test system is used for functional testing of a Bluetooth product:
page 11 2nd paragraph : “The system of claim 3, wherein the test control device is further provided with a continuous integration tool for detecting an update of the protocol stack application and compiling the protocol stack application.”;
page 3 9th paragraph : “Thus, the test control instructions can include test control instructions for basic functional testing and/or test control instructions for compatibility testing. Test
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Luo into teachings of Jalal and Kolesnik and Spittle for an efficient testing of Bluetooth devices including basic function and compatibility tests. Using different testing platform, the server can integrate any devices resulting in efficient Bluetooth test, versatility and scalability of the test platform [LUO page 2 first paragraph].
Claims 15 is rejected under 35 U.S.C. 103 as being unpatentable Jalal et al US20230305813A1 in view of Kolesnik et al US20160239295A1, Spittle et al US20230300532A1 and further in view of Jones et al US20200218634A1 and LUO et al WO2019090454A1 .
As per claim 15 the rejection of claim 1 is incorporated and furthermore Jalal discloses:
wherein: the host server is further configured to execute :sending the review result to a code source end in response to that the review result indicates "not pass":
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0007] to determine passing/failed test case.
Jalal discloses a system of CI/CD executed by a processor in CI/CD pipeline[0071] to determine[0063] if all or at least one of the test is/are failed.
Examiner interpretation:
[0063] “At step 325, a determination is made as to whether the source code and executable program are valid and/or are of sufficient quality. If the source code and executable program are invalid (do not meet all or a portion of the requirements of the QMS) and/or the source code and executable program are of poor quality (as defined and measured by the software development system in accordance with the QMS), then the CI of the software development system forwards the source code back to the development team to fix the failures and/or quality of the source code”;
See also kolesnik [0032 and 0046]
sending the full test result to the code source end in response to that the full test result indicates "not pass":
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0007] to determine passing/failed test case.
Jalal discloses a system of CI/CD executed by a processor in CI/CD pipeline[0071] to determine[0063, 0069] if all or at least one of the test is/are failed.
Examiner interpretation:
[0069]“ In some instances, the quality and compliance or noncompliance determination is an all or nothing determination, e.g., the source code must meet all requirements to be considered to have adequate quality and compliance.
…
In contrast, if the different analysis techniques demonstrate that the source code does not have adequate quality and compliance, then a notification may be sent to the actor and/or administrators of the software platform. The notification identifies the source code and the reasons for the failed verification. The execution of the test plan and results of the verification are recorded in a manner to maintain traceability between feature requirements, test plan for the feature requirements, and evidence supporting the test plan was executed. The record will be maintained in a repository for future use, e.g., to support government regulatory review.”;
But not explicitly:
sending the compiling result to the code source end in response to that the compiling result indicates "not success";
marking the submitted code as "can be merged" in response to that the full test result indicates "pass"; and merging the submitted code into a full code in response to that the full test result indicates "pass"
each of the working stations comprises a slave server, a development board, a control board, and at least one test sensing device, wherein: the slave server sends a test command to the development board according to the compiled code so that the development board generates a response, wherein the test command is at least one selected from the group consisting of a first control command and a second control command, and the second control command is sent to the development board through the control board; the test sensing device sends the response of the development board to the slave server; and wherein the host server obtains the full test result according to the response of the development board; and the automated integration and test system is used for functional testing of a Bluetooth product.
Kolesnik discloses:
marking the submitted code as "can be merged" in response to that the full test result indicates "pass";
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0015] to determine passing and code merging.
Kolesnik discloses a CI of the software development system executed by system 400 of fig. 4 to indicate [0024] that the code is ready for merging based on success testing
Examiner interpretation:
[0024] “The source code review system 130 may rank the given code change in view of input from the client devices 110a-z, the CI system 140, and/or the deployment system 150. For example, the source code review system 130 may rank the code change as “ready to be merged” in response to receiving input indicating that the reviewers have approved the code change and/or that the code change passes one or more tests executed by the CI system 140 and/or the deployment system 150”;
and merging the submitted code into a full code in response to that the full test result indicates "pass":
This element is interpreted under 35 U.S.C. 112(f) as the server 200 with a memory [0013] on SoC executing steps of [0006] to determine passing/failed test case.
Kolesnik discloses a CI of the software development system executed by system 400 of fig. 4 to indicate [0031] that the code can be merged based on success testing
Examiner inte