DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the amendment filed October 30, 2025.
Claims 1-20 are pending.
Response to Arguments
Applicant's arguments filed October 30, 2025 have been fully considered but they are not persuasive. In Remarks, Pages 12-13 submitted October 30, 2025 regarding the rejections under §103, the Examiner respectfully disagrees. Specifically, Applicant’s argues that the combination of references does not teach a system to “identify which variants are "compliant," i.e., compatible and functionally suitable for inclusion together…” limitations which are not in the claims 1, 8 and 15.In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “compatible and functionally suitable for inclusion together”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Here, a broad but reasonable interpretation of applicant’s claimed “compliant variants” is read on by the plug-in variants with signatures which are digital certified as in Gaither. Applicant has the ability to amend the claims to more specifically claim the particular type of compliance argued in applicant’s remarks, but where applicant has declined to do so, such limitations will not be read into the claims. As such the argument is unpersuasive and the rejection is maintained.
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.
Claim(s) 1-4,7-16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “King” (US PG Pub 2022/0358598) in view of “Gaither” (US PG Pub 2015/0039515)
Regarding Claim 1, King teaches:
A method, comprising: storing, by a device and in a data structure, a plurality of feature variants associated with a schema of software and (See 122, 124, 114 Fig. 2, ¶¶27-28,40-43 teaching a software experiment system including multiple UI and logic variants in a user application which are selected by the experiment manager to be activated for different segments of users based on context data where the variants are stored in the application 102 and the variant ids are stored in data strucutres (e.g. ¶43) and used 118, fig 2, to activate particular variants for the experiments)
identifying, by the device and in the data structure, a set of feature variants, from the plurality of feature variants, based on the experiment information; (See 122, 124, 114 Fig. 2, ¶¶27-28,40-43 teaching a software experiment system including multiple UI and logic variants in a user application which are selected by the experiment manager to be activated for different segments of users based on context data where the variants are stored in the application 102 and the variant ids are stored in data strucutres (e.g. ¶43) and used 118, fig 2, to activate particular variants for the experiments)
generating, by the device, compliant feature variants (See 122, 124, 114 Fig. 2, ¶¶27-28,40-43 teaching a software experiment system including multiple UI and logic variants in a user application which are selected by the experiment manager to be activated for different segments of users based on context data where the variants are stored in the application 102 and the variant ids are stored in data strucutres (e.g. ¶43) and used 118, fig 2, to activate particular variants for the experiments)
defining, by the device, segments and metrics for the software experiment based on the compliant feature variants; (¶¶13,48-51 126, Fig. 2 of King teaches identifying metrics and segments of users for the experiment by the experiment manager 104, fig 2)
generating, by the device, the software experiment based on the compliant feature variants, the segments, and the metrics; (120, Fig. 2, ¶¶35-37,39,40,42 teaches creating the software experiment by the experiment manager by sending variant ids to the user device based on context data)
executing, by the device, the software experiment to generate results; and (See e.g. ¶¶38-39 of King teaches executing the specified variants and collecting results to carry out the experiement) performing, by the device, one or more actions based on the results. (See King 512, Fig. 5, ¶134 teaches providing recommendations based on the results of the experiment)
King does not explicitly teach, but Gaither teaches:
…signatures generated based on the schema; (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested)
providing, by the device, a user interface that requests experiment information associated with generating a software experiment; (Gaither ¶¶23,36 teaches a UI for entering information related to variants for experiment which can be used to facilitate the software experiment)
receiving, by the device and via the user interface, the experiment information associated with generating the software experiment; (Gaither ¶¶23,36 teaches a UI for entering information related to variants for experiment which can be used to facilitate the software experiment)
identifying, by the device, a set of corresponding signatures for the set of feature variants; (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested)
comparing, by the device, signatures of the set of corresponding signatures to identify compliant signatures of the set of corresponding signatures; (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested)
…based on the compliant signatures, wherein each compliant feature variant is determined from performing one or more operations on each feature variant of the set of feature variants that correspond to the compliant signatures; (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested; further in ¶¶23,37 teaches carrying out the certification operation on the digital signature for the plug-in variants )
In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of King and Gaither as each is directed to variant testing systems and Gaither recognized “What is needed are improved techniques for determining desirable product improvements for software applications. Accordingly, interactive product improvement through the use of variants and data gathering reports in a system that can be updated on the fly is provided in accordance with some embodiments.” (¶14).
Regarding Claim 8, King teaches:
8. A device, comprising: one or more memories;
and one or more processors, (King 608, Fig. 6)
coupled to the one or more memories, (King 604, Fig. 6) configured to: receive software that includes a plurality of feature variants associated with a schema; (102, 112, 114 Fig. 2, ¶¶27-28 teaches a user application including UI and logic variants for execution on a user device)
store, in a data structure, the plurality of feature variants and (See 122, 124, 114 Fig. 2, ¶¶27-28,40-43 teaching a software experiment system including multiple UI and logic variants in a user application which are selected by the experiment manager to be activated for different segments of users based on context data where the variants are stored in the application 102 and the variant ids are stored in data strucutres (e.g. ¶43) and used 118, fig 2, to activate particular variants for the experiments)
identify, in the data structure, a set of feature variants, from the plurality of feature variants, based on the experiment information; (See 122, 124, 114 Fig. 2, ¶¶27-28,40-43 teaching a software experiment system including multiple UI and logic variants in a user application which are selected by the experiment manager to be activated for different segments of users based on context data where the variants are stored in the application 102 and the variant ids are stored in data strucutres (e.g. ¶43) and used 118, fig 2, to activate particular variants for the experiments)
generate compliant feature variants (See 122, 124, 114 Fig. 2, ¶¶27-28,40-43 teaching a software experiment system including multiple UI and logic variants in a user application which are selected by the experiment manager to be activated for different segments of users based on context data where the variants are stored in the application 102 and the variant ids are stored in data strucutres (e.g. ¶43) and used 118, fig 2, to activate particular variants for the experiments)
define segments and metrics for the software experiment based on the compliant feature variants; (¶¶13,48-51 126, Fig. 2 of King teaches identifying metrics and segments of users for the experiment by the experiment manager 104, fig 2)
generate the software experiment based on the compliant feature variants, the segments, and the metrics; (120, Fig. 2, ¶¶35-37,39,40,42 teaches creating the software experiment by the experiment manager by sending variant ids to the user device based on context data) execute the software experiment to generate results; (See e.g. ¶¶38-39 of King teaches executing the specified variants and collecting results to carry out the experiement)and perform one or more actions based on the results. (See King 512, Fig. 5, ¶134 teaches providing recommendations based on the results of the experiment)
King does not explicitly teach, but Gaither teaches:
…signatures generated based on the schema; (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested)
provide a user interface that requests experiment information associated with generating a software experiment; (Gaither ¶¶23,36 teaches a UI for entering information related to variants for experiment which can be used to facilitate the software experiment) receive, via the user interface, the experiment information associated with generating the software experiment; (Gaither ¶¶23,36 teaches a UI for entering information related to variants for experiment which can be used to facilitate the software experiment)
identify a set of corresponding signatures for the set of feature variants; (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested)
compare signatures of the set of corresponding signatures to identify compliant signatures of the set of corresponding signatures; (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested)
,,,based on the compliant signatures wherein each compliant feature variant is determined from performing one or more operations on each feature variant of the set of feature variants that correspond to the compliant signatures; (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested; further in ¶¶23,37 teaches carrying out the certification operation on the digital signature for the plug-in variants )
In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of King and Gaither as each is directed to variant testing systems and Gaither recognized “What is needed are improved techniques for determining desirable product improvements for software applications. Accordingly, interactive product improvement through the use of variants and data gathering reports in a system that can be updated on the fly is provided in accordance with some embodiments.” (¶14).
Regarding Claim 15, King teaches:
15. A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a device, cause the device to: store, in a data structure, a plurality of feature variants associated with a schema of software (See 122, 124, 114 Fig. 2, ¶¶27-28,40-43 teaching a software experiment system including multiple UI and logic variants in a user application which are selected by the experiment manager to be activated for different segments of users based on context data where the variants are stored in the application 102 and the variant ids are stored in data strucutres (e.g. ¶43) and used 118, fig 2, to activate particular variants for the experiments)
wherein the plurality of feature variants includes one or more of: one or more software components, one or more software models, one or more application programming interfaces, or one or more user interface elements; (See e.g. King 112,114,Fig. 2, ¶¶27-28 teaching UI and logic variants in the application)
identify, in the data structure, a set of feature variants, from the plurality of feature variants, based on the experiment information; (See 122, 124, 114 Fig. 2, ¶¶27-28,40-43 teaching a software experiment system including multiple UI and logic variants in a user application which are selected by the experiment manager to be activated for different segments of users based on context data where the variants are stored in the application 102 and the variant ids are stored in data strucutres (e.g. ¶43) and used 118, fig 2, to activate particular variants for the experiments)
generate compliant feature variants…(See 122, 124, 114 Fig. 2, ¶¶27-28,40-43 teaching a software experiment system including multiple UI and logic variants in a user application which are selected by the experiment manager to be activated for different segments of users based on context data where the variants are stored in the application 102 and the variant ids are stored in data strucutres (e.g. ¶43) and used 118, fig 2, to activate particular variants for the experiments)
define segments and metrics for the software experiment based on the compliant feature variants; (¶¶13,48-51 126, Fig. 2 of King teaches identifying metrics and segments of users for the experiment by the experiment manager 104, fig 2) generate the software experiment based on the compliant feature variants, the segments, and the metrics; (120, Fig. 2, ¶¶35-37,39,40,42 teaches creating the software experiment by the experiment manager by sending variant ids to the user device based on context data) execute the software experiment to generate results; (See e.g. ¶¶38-39 of King teaches executing the specified variants and collecting results to carry out the experiement) and perform one or more actions based on the results. (See King 512, Fig. 5, ¶134 teaches providing recommendations based on the results of the experiment)
King does not explicitly teach, but Gaither teaches:
…and signatures generated based on the schema, (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested)
provide a user interface that requests experiment information associated with generating a software experiment; (Gaither ¶¶23,36 teaches a UI for entering information related to variants for experiment which can be used to facilitate the software experiment)receive, via the user interface, the experiment information associated with generating the software experiment; (Gaither ¶¶23,36 teaches a UI for entering information related to variants for experiment which can be used to facilitate the software experiment)
identify a set of corresponding signatures for the set of feature variants; (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested) compare signatures of the set of corresponding signatures to identify compliant signatures of the set of corresponding signatures; (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested)
…based on the compliant signatures wherein each compliant feature variant is determined from performing one or more operations on each feature variant of the set of feature variants that correspond to the compliant signatures; (Gaither e.g. ¶¶23,36-37 teaches using digital certificates associated with the variants for certifications of the variants to be tested; further in ¶¶23,37 teaches carrying out the certification operation on the digital signature for the plug-in variants )
In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of King and Gaither as each is directed to variant testing systems and Gaither recognized “What is needed are improved techniques for determining desirable product improvements for software applications. Accordingly, interactive product improvement through the use of variants and data gathering reports in a system that can be updated on the fly is provided in accordance with some embodiments.” (¶14).
Regarding the dependent claims King and Gaither further teach:
2. The method of claim 1, further comprising: receiving the software that includes the plurality of feature variants associated with the schema. (See King 102, 112, 114 fig. 2, ¶¶27-28,40-43 teaches deploying application 102 to user devices including variants 112, 114)
3. The method of claim 1, wherein the plurality of feature variants includes one or more of: one or more software components, one or more software models, one or more application programming interfaces, or one or more user interface elements. (See e.g. King 112,114,Fig. 2, ¶¶27-28 teaching UI and logic variants in the application)
4. The method of claim 1, wherein storing, in the data structure, the plurality of feature variants and the signatures comprises: storing, in the data structure, one or more of the schema, resource identifiers, descriptions, or parameters associated with the software. (King 120, Fig. 2, ¶43,34-35 teaches storing variant results information in a data structure as well as descriptions, identifiers thereof)
7. The method of claim 1, wherein each of the segments includes a set of users, user devices, or user accounts. (See e.g. King ¶¶13,34,35 describing selecting the sets of users for variant application).
9. The device of claim 8, wherein the metrics include business metrics or technical metrics. (See King ¶¶36,48 teaches recording metrics related to variant usage such as user clicks for the variants).
10. The device of claim 8, wherein the one or more processors are further configured to: enable inspection of one or more of the compliant feature variants prior to executing the software experiment. (Gaither e.g. Fig. 3, ¶¶39-40 teaches a manifest which may be inspected related to the different variants of the software experiment) In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of King and Gaither as each is directed to variant testing systems and Gaither recognized “What is needed are improved techniques for determining desirable product improvements for software applications. Accordingly, interactive product improvement through the use of variants and data gathering reports in a system that can be updated on the fly is provided in accordance with some embodiments.” (¶14).
11. The device of claim 8, wherein the one or more processors are further configured to: enable execution of one or more of the compliant feature variants prior to executing the software experiment. (King experiment manager 104 uses 118 to enable execution of a variant as in ¶102)
12. The device of claim 8, wherein the one or more processors, to perform the one or more actions, are configured to one or more of: provide the results for display, provide, for display, documentation, code, and sample data associated with the software experiment, or generate software code based on the software experiment and implement the software code. (See e.g. King ¶¶53,88 teaches displaying experiment information and results in a Dashboard or other UI).
13. The device of claim 8, wherein the one or more processors, to perform the one or more actions, are configured to: modify the software experiment based on the results and to generate a modified software experiment; (see e.g. King ¶¶37,92-93 teaches modifying the variants based on input data to the experiment, which may be re-executed by the experiment manager)and execute the modified software experiment to generate additional results. (see e.g. King ¶¶37,92-93 teaches modifying the variants based on input data to the experiment, which may be re-executed by the experiment manager)
14. The device of claim 8, wherein the one or more processors, to perform the one or more actions, are configured to: modify one or more of the compliant feature variants based on the results and to generate a modified software experiment; (see e.g. King ¶¶37,92-93 teaches modifying the variants based on input data to the experiment, which may be re-executed by the experiment manager) and execute the modified software experiment. (see e.g. King ¶¶37,92-93 teaches modifying the variants based on input data to the experiment, which may be re-executed by the experiment manager)
16. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions, that cause the device to store, in the data structure, the plurality of feature variants and the signatures, cause the device to: store, in the data structure, one or more of the schema, resource identifiers, descriptions, or parameters associated with the software. (King 120, Fig. 2, ¶43,34-35 teaches storing variant results information in a data structure as well as descriptions, identifiers thereof)
18. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions further cause the device to one or more of: enable inspection of one or more of the compliant feature variants prior to executing the software experiment, or enable execution of one or more of the compliant feature variants prior to executing the software experiment. (Gaither e.g. Fig. 3, ¶¶39-40 teaches a manifest which may be inspected related to the different variants of the software experiment) In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of King and Gaither as each is directed to variant testing systems and Gaither recognized “What is needed are improved techniques for determining desirable product improvements for software applications. Accordingly, interactive product improvement through the use of variants and data gathering reports in a system that can be updated on the fly is provided in accordance with some embodiments.” (¶14).
19. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions, that cause the device to perform the one or more actions, cause the device to one or more of: provide the results for display, provide, for display, documentation, code, and sample data associated with the software experiment, or generate software code based on the software experiment and implement the software code. (See e.g. King ¶¶53,88 teaches displaying experiment information and results in a Dashboard or other UI). -
20. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions, that cause the device to perform the one or more actions, cause the device to: modify the software experiment based on the results and to generate a modified software experiment; (see e.g. King ¶¶37,92-93 teaches modifying the variants based on input data to the experiment, which may be re-executed by the experiment manager) and execute the modified software experiment to generate additional results. (see e.g. King ¶¶37,92-93 teaches modifying the variants based on input data to the experiment, which may be re-executed by the experiment manager)
Claim(s) 5,6, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over “King” (US PG Pub 2022/0358598) in view of “Gaither” (US PG Pub 2015/0039515) as applied above and further in view of “Magnuson” (US Patent 11,886,434).
Regarding Claim 5, King et al do not further teach, but Magnuson teaches:
5. The method of claim 1, wherein each of the signatures includes information identifying one or more of: a type associated with one of the plurality of feature variants, a model associated with one of the plurality of feature variants, functionality associated with one of the plurality of feature variants, inputs associated with one of the plurality of feature variants, outputs associated with one of the plurality of feature variants, or measurement criteria associated with one of the plurality of feature variants. (Magnuson Col. 74, Ln 40-51 teaches a set of signatures each associated with a function represented in the metadata where the signatures are checked to verify the authenticity of the function represented by the signature). In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of King and Manguson as each is directed to software testing systems and Manguson recognized the utility of “packages include multiple entities and the metadata describing each entity in the package, as well as additional metadata describing the package. A package can also include licensing information as described further below. License terms may be enforced automatically at runtime using hashing and signatures as described below.” (Col. 10, Ln 16-37).
Regarding Claim 6, King et al do not further teach, but Magnuson teaches:
6. The method of claim 1, wherein comparing the signatures of the set of corresponding signatures to identify the compliant signatures of the set of corresponding signatures comprises one or more of: comparing functionalities of the signatures to identify the compliant signatures of the set of corresponding signatures, or comparing combinations of functionalities of the signatures to identify the compliant signatures of the set of corresponding signatures. (Magnuson Col. 74, Ln 40-51 teaches a set of signatures each associated with a function represented in the metadata where the signatures are checked to verify the authenticity of the function represented by the signature). In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of King and Manguson as each is directed to software testing systems and Manguson recognized the utility of “packages include multiple entities and the metadata describing each entity in the package, as well as additional metadata describing the package. A package can also include licensing information as described further below. License terms may be enforced automatically at runtime using hashing and signatures as described below.” (Col. 10, Ln 16-37).
Regarding Claim 17, King et al do not further teach, but Magnuson teaches:
17. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions, that cause the device to compare the signatures of the set of corresponding signatures to identify the compliant signatures of the set of corresponding signatures, cause the device to: compare functionalities of the signatures to identify the compliant signatures of the set of corresponding signatures, or compare combinations of functionalities of the signatures to identify the compliant signatures of the set of corresponding signatures. (Magnuson Col. 74, Ln 40-51 teaches a set of signatures each associated with a function represented in the metadata where the signatures are checked to verify the authenticity of the function represented by the signature). In addition it would have been obvious to one of ordinary skill prior to the effective filing date of the application to combine the teachings of King and Manguson as each is directed to software testing systems and Manguson recognized the utility of “packages include multiple entities and the metadata describing each entity in the package, as well as additional metadata describing the package. A package can also include licensing information as described further below. License terms may be enforced automatically at runtime using hashing and signatures as described below.” (Col. 10, Ln 16-37).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The Additional Prior art cited in the attached PTO-892 form includes prior art relevant to applicant’s disclosures related to systems for variant software experiment testing.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 MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Monday-Friday, 9am-4:30pm.
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, Wei Zhen can be reached at 571-272-3708. 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.
MJB
2/18/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191