DETAILED ACTION
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/05/2025 has been entered. An action on the RCE follows.
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.
Status of the application
This Office Action is in response to Applicant's arguments filed on12/05/2025. Claims 1-2, and 4-8 are pending for this examination.
Acknowledgement
This Office action has been issued in response to reconsideration request filed on 12/05/2025.
Claims 1, 2, and 4-8 are pending.
No claims have been amended.
Response to Arguments
Applicant’s arguments have been considered but are not found persuasive. Applicant’s arguments in substance are as follows:Applicant argues on page 6, paragraph 3 of the “Remarks” section, "The Applicant respectfully disagrees with the Examiner's characterization that claims 1 and 6 are directed to "software per se." The Examiner's rejection is based on an overly narrow
interpretation of the term "processing module" and fails to consider the claims in light of the complete specification, which clearly describes a hardware system with interconnected physical components."
Examiner’s Response: Examiner respectfully disagrees. Please note that examination considers the broadest reasonable interpretation of terms. Although in most case a processing module may mean a hardware component, processing module includes software modules also. As such, it is required to specify processing module is a hardware component. Amendment such as “processing module, comprising: a processor”, can overcome the rejection. Please note axis.com (document attached) recites “A processing module, or a just module, is an abstract concept. A module has a type and can be instantiated, similar to a class in most programming languages.” Examiner could not find any location in the original disclosure where “processing module” has been described or defined as a piece of hardware. Figures in the drawings show some boxes with labels without any information that the box is a piece of hardware or software or a function or a human.
Applicant argues on page 12, paragraph 1 of the “Remarks” section, “For "user action performer and recommendation" (item iv), lines 169-171 list "l 70a - User Action Performer" and" 170b - Recommendation Engine" as separate reference numerals, indicating these are functional components of the system. The specification describes that the system reacts to user actions and provides recommendations based on those actions. One skilled in the art would understand this refers to the operational function of: (a) performing/capturing user actions, and (b) generating recommendations based on those actions.”
Examiner’s Response: The purpose of this argument is unclear. Examiner did not reject this limitation.
Applicant argues on page 12, paragraph 2 of the “Remarks” section, “For "emotion narrator and feedback storage" (item v), lines 168-170 list "200 - Emotion
Narrator," "200a - SME UP," and "200b - Feedback Store" as reference numerals. Lines 255-258 describe: ''Aggregator then sends the data to UE Emotion Translator (190) which will translate the emotion rating into the possible end user feedback attached with the emotion (200, 200a, 200b) ". One skilled in the art would understand this refers to the operational function of: (a) narrating/expressing user emotions, and (b) storing feedback data.”
Examiner’s response: Please note that it is improper to import claim limitations from the specification (MPEP 2111.01 II). Please note that the claim limitation recites “emotional narrator and feedback”, where “emotional narrator” and “feedback” both are nouns. An operational step is expected to have at least one verb.
Applicant argues on page 13, paragraph 2 of the “Remarks” section, “The Examiner notes that it is unclear "prediction of what and prescription for what." Applicant respectfully submits that one of ordinary skill in the art, reading the limitation in the
context of the entire claim and specification, would understand this limitation with reasonable certainty. The preamble of claim I recites: ''A system for engineering a user experience (UE)" and Item i recites: "rating and scoring a user experience (UE) ". Hence, the claims describe analysing user experience data throughout.
One skilled in the art would immediately understand that ''prediction and prescription" in
the context of user experience engineering refers to:
• Prediction: predicting user experience outcomes, issues, problems, or ratings; and
• Prescription: prescribing solutions, improvements, remedial actions, or recommendations”.
Examiner’s Response: The argument that “Prediction: predicting user experience outcomes, issues, problems, or ratings; and
• Prescription: prescribing solutions, improvements, remedial actions, or recommendations”. The interpretation of these two terms “prediction” and “prescription” has not been defined or described anywhere in the original disclosure. Specification recites on page 5, “100a – Prediction, 100b – Prescribe”. There is no other description or explanation of these terms. Figures in the drawings show two boxes with labels 100a and 100bb without any further description of these terms. The above descriptions of the terms, is the understanding of the terms by the applicant. However, this description cannot be used in the claims, as these will create new matter.
Applicant argues on page 14, paragraph 2 of the “Remarks” section, “One skilled in the art would understand that "recommendation" refers to recommendations for improving user experience, addressing user issues, or guiding user actions, all in the context of user experience engineering.”
Examiner’s response: The above interpretation of the term “recommendation” is not found anywhere in the specification or drawings.
Examiner’s comments: In the examiner’s opinion, the application could have been allowable with proper documentation. The disclosure does not explain the terms used in the claims. As such, the meanings of the terms are unknown and makes the claims indefinite. However, adding any description or definition of terms creates new matter issue. As such, the examiner believes the application is not allowable.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Software per se
Claims 1 and 6 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims refer to a system. The instant specification has provided evidence that the claimed system is a software per se, wherein a series of modules are to be executed. The claims do not define structural and functional descriptive material used in interrelationship between the computer software and the hardware like a memory or processor. Descriptive material can be characterized as either “functional descriptive material” or “nonfunctional descriptive material.” Both types of “descriptive material” are non-statutory when claimed as descriptive material per se, 33 F.3d at 1360, 31 USPQ2d at 1759. When functional descriptive material is recorded on some computer-readable medium, it becomes structurally and functionally interrelated to the medium and will be statutory in most cases since use of technology permits the function of the descriptive material to be realized. Compare In re Lowry, 32 F.3d 1579, 1583-84, 32 USPQ2d 1031, 1035 (Fed. Cir. 1994).
Claim 1 recites “A system for engineering a user experience (UE), comprising: …a processing module configured to execute a system operation…”. The term processing module has not been defined or described in the disclosure. It is unclear this is a hardware or software module. As such, using broadest reasonable interpretation, this claim is considered a software per se. Claim 6 has substantially similar claim limitation as above and can be rejected for the same reason. Examiner suggests using the word “processor” which is a known term in the art, instead of “processing module” which does not have a definition.
Claims 2, 4, 5, 7 and 8 are rejected for being dependent on a rejected base claim.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1, 6 and 7 rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 1 recites “a processing module configured to execute a system operation which comprises of:..” followed by some operational steps. However, some of the steps mentioned are not operational steps. For example, claim recites:“iv. a user action performer and recommendation; and v. an emotion narrator and feedback storage;”. Here “a user action performer” and “an emotion narrator” are not steps of the operation but they are some of the components of the system. In addition, in the limitation “iii. Prediction and prescription”, it is unclear from the claim, prediction of what and prescription for what. Possibly the limitation meant to be prediction of errors and prescription for remedy the errors. However, it is unclear from the claim. Limitation iv recites “a user action performer and recommendation;”. It is unclear recommendation for what.
Hence these limitations become unclear.
Examiner would suggest the following amendments to make the steps consistent. Please note that this is just a suggestion from the examiner’s understanding of the intention of the claim limitations.
“a processing module configured to execute a system operation which comprises of:
i. rating and scoring a user experience (UE);ii. Storing a subject matter expert’s input and feedback;
iii. predicting ??? and creating proper prescription for the predicted results;
iv. capturing users’ actions and making proper recommendation for ???? using the users’ actions;
v. capturing and storing users’ emotion and user feedback;”.
Claim 1 further recites “c. in turn, the aggregator (140) then sends data to a UE emotion translator module (190) which will translate the data into an emotion rating thereby predicting an end user's feedback;”. Here future tense is used in the claim limitation. "An example may be "working" or "prophetic". "A working example is based on work actually performed. A prophetic example describes an embodiment of the invention based on predicted results rather than work actually conducted or results actually achieved." (See MPEP 2164.02). As such, this limitation teaches that work has not been performed.
Claim 6 recites “a processing module configured to execute a system operation which comprises of:..” followed by some operational steps. However, some of the steps mentioned are not operational steps. For example, claim recites:“iv. a user action performer and recommendation; and v. an emotion narrator and feedback storage;”. Here “a user action performer” and “an emotion narrator” are not steps of the operation but they are some of the components of the system. In addition, limitation iii recites “iii. Prediction and prescription”, it is unclear from the claim, prediction of what and prescription for what. Possibly the limitation meant to be prediction of errors and prescription for remedy the errors. However, it is unclear from the claim. Limitation iv recites “a user action performer and recommendation;”. It is unclear recommendation for what. Hence these limitations are unclear.
Please see the rejection for claim 1 above for some suggestions from the examiner for some probable amendment.
Claim 6 recites “wherein the system is configured to analyse data from stages in the product or a service lifecycle….”. There is not previous mention of a product. As such, the limitation lacks antecedent basis.
Claim 6 further recites “generate artefacts which are functional, technical requirements, tests, test data, and test environment (TE) configurations, comprise:
a. an iTriager module (301) configured to take feed from post experience data
along with a defect store (300a) and SME input (300b) to determine validity of
defects identified, including known or, duplicate defects and transmit validated defect data to an iResolver module (303) for further processing;….”.
It is unclear what “comprise:” the iTriager module. From the wording it appears that “generate artefacts which are functional, technical requirements, tests, test data, and test environment (TE) configurations” comprise the iTriager. However, that appears to be incorrect. Possibly “the system comprises” the following steps mentioned in the claim.
Claim 6 recites “d. if a test is not available, the module will help generate the test case, script and test data to execute the test cases against the fix delivered;”. It is not clear which module is being referred here.
Claim 7 recites “wherein a RAG (Red, Amber, Green) configurator module (10) is configured to receive input from SME inputs (11) and industry benchmarks (12) to configure the data and send it to a weightage configurator module (18), which then sends the data to the aggregator (140).” Here it is unclear which data are referred by “the data”.
References of Note
Examiner has cited particular columns, line numbers, references, or figures in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses to fully consider the reference in entirety, as potentially teaching all or part of the claimed invention. See MPEP §§ 2141.02 and 2123.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOSSAIN MORSHED whose telephone number is (571)272-3335. The examiner can normally be reached on Monday – Friday12:00 PM – 9 PM Eastern Time. The email address for the examiner is hossain.morshed@uspto.gov.
Examiner interviews are available via telephone or 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 Mui can be reached on (571)272-3708.
/HOSSAIN M MORSHED/Primary Examiner, Art Unit 2191
December 23, 2025
Prosecution Insights