DETAILED ACTION
This Non-Final Office Action is in response to Applicant's amendments and arguments and request for continued examination filed on March 16, 2026. Applicant has amended claims 1, 5, 7-8, 12, 14-15, 19, canceled claim 20 and added claim 21. Currently, claims 1-19, 21 are pending. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 3/16/26 has been entered.
Response to Amendments
The 35 U.S.C. 101 rejections of claims 1-19 are maintained in light of applicant’s amendments.
The 35 U.S.C. 103 rejections of claims 1-19 are maintained in light of applicant’s amendments.
Response to Arguments
Applicant’s remarks submitted on 3/16/26 have been considered but are not persuasive. Applicant argues on p. 8 of the remarks that the 103 rejections are improper. Applicant argues that the prior art does not show the amended language. Examiner disagrees and notes that Murthi shows at [0002], "Customer health is a metric that is used to measure the well-being of a customer's relationship with a client whose product and/or services are being used or consumed by the customer." which therefore supports customer health as being the health of a service and para [0015]-[0019] further shows conversation log entries for the support ticket that is associated with metadata where the different communication entries can be considered incidents given broadest reasonable interpretation of incident. Therefore, the claims remain rejected under 103. Applicant further argues on p. 9 of the remarks that the 101 rejections are improper. Examiner disagrees. Applicant argues that the claims do not recite an abstract idea because, for instance, the example of rearranging icons. Examiner notes applicant’s claims are not equivalent to that example. Applicant further argues that the claims show technical benefits. Examiner disagrees and notes the claims use technology to improve the abstract idea itself. Therefore, the claims remain rejected under 101.
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.
Claims 1-19, 21 are clearly drawn to at least one of the four categories of patent eligible subject matter recited in 35 U.S.C. 101 (apparatus, method and computer program product). Claims 1-19, 21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claims 1, 8 and 15 recite the abstract idea of receiving a contextualized support ticket visualization request from a support provider and accessing a support ticket data object from a ticket-based service managing system based at least in part on the support ticket and accessing a support seeker data object from an asset-based data tracking system based at least in part on the support seeker and generating a contextualized support ticket user. The claims are directed to a type of managing of support tickets for a support seeker. Under prong 1 of Step 2A, these claims are considered abstract because the claims are certain methods of organizing human activity including commercial interactions such as business relations. Applicant’s claims are show requests by support seekers (human interactions that can be considered commercial) where the requested data is organized by the generated support ticket. Under prong 2 of Step 2A, the judicial exception is not integrated into a practical application because the claims (the judicial exception and any additional elements individually or in combination such as an apparatus comprising at least one processor and at least one non-transitory memory comprising program code, the at least one non-transitory memory and the program code configured to, with the at least one processor, cause the apparatus to perform steps, a computer implemented method, computer program product comprising at least one non-transitory computer- readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising an executable portion configured to perform steps and a computing device, wherein the contextualized support ticket visualization request comprises support ticket identifying metadata and wherein the support ticket data object comprises product and service context metadata and identifying metadata, wherein the support seeker data object comprises support seeker context metadata and causing generating a contextualized support ticket user interface on the support provider computing device, wherein the contextualized support ticket user interface comprises a support seeker context user interface component based at least in part on the product and service context metadata, wherein the support seeker context user interface component comprises a product and service context metadata user interface element wherein the product and service context metadata user interface element comprises a service health and incidents metadata portion indicating health and incident status of one or more services associated with the support seeker identifying metadata are not an improvement to a computer or a technology, the claims do not apply the judicial exception with a particular machine, the claims do not effect a transformation or reduction of a particular article to a different state or thing nor do the claims apply the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment such that the claims as a whole is more than a drafting effort designed to monopolize the exception. These limitations at best are merely implementing an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements individually or in combination such as an apparatus comprising at least one processor and at least one non-transitory memory comprising program code, the at least one non-transitory memory and the program code configured to, with the at least one processor, cause the apparatus to perform steps, a computer implemented method, computer program product comprising at least one non-transitory computer- readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising an executable portion configured to perform steps and a computing device, wherein the contextualized support ticket visualization request comprises support ticket identifying metadata and wherein the support ticket data object comprises product and service context metadata and identifying metadata, wherein the support seeker data object comprises support seeker context metadata and causing generating a contextualized support ticket user interface on the support provider computing device, wherein the contextualized support ticket user interface comprises a support seeker context user interface component based at least in part on the product and service context metadata, wherein the support seeker context user interface component comprises a product and service context metadata user interface element wherein the product and service context metadata user interface element comprises a service health and incidents metadata portion indicating health and incident status of one or more services associated with the support seeker identifying metadata (as evidenced by para [0083]-[0095], [0113]-[0121] of applicant’s own specification) are well understood, routine and conventional in the field. Dependent claims 2, 5-6, 9, 12-14, 16, 19 also do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements either individually or in combination are merely an extension of the abstract idea itself by further showing a support ticket description user interface component displayed adjacent to the support seeker context user interface component and receive a support seeker organization visualization request and access one or more support seeker data objects from the asset-based data tracking system based at least in part on the support provider. Dependent claims 3-5, 7, 10-12, 14, 17-19, 21 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements individually or in combination such as wherein the support seeker data object comprises customer context metadata and , wherein the support seeker context user interface component comprises a customer context metadata user interface element based at least in part on the customer context metadata and support provider computing device, wherein the support seeker organization visualization request comprises support provider identifying metadata and based at least in part on the support provider identifying metadata and cause generating a support seeker organization overview user interface on the support provider computing device based at least in part on the one or more support seeker data objects and support provider computing device, wherein the support seeker contact visualization request comprises support provider identifying metadata wherein the support seeker organization visualization request comprises support provider identifying metadata indicating that a support provider associated with the support provider computing device is allocated to an organization associated with the support seeker organization visualization request and based at least in part on the support provider identifying metadata and cause generating a support seeker contact overview user interface on the support provider computing device based at least in part on the one or more support seeker data objects and wherein the product and service context metadata user interface element comprises an upcoming service changes metadata portion indicating one or more upcoming service changes associated with the one or more services (as evidenced by para [0083]-[0095], [0113]-[0121] of applicant’s own specification) are well understood, routine and conventional in the field.
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-19, 21 are rejected under 35 U.S.C. 103 as being unpatentable over Ashby (US 2023/0289817 A1) (hereinafter Ashby) in view of Murthi et al. (US 2024/0161121 A1) (hereinafter Murthi).
Claims 1, 8 and 15:
Ashby, as shown, discloses the following limitations of claims 1, 8 and 15:
An apparatus (and corresponding computer-implemented method and computer program product - see para [0136]-[0137] and Fig 1 showing equivalent computer functionality) comprising at least one processor and at least one non-transitory memory comprising program code, the at least one non-transitory memory and the program code configured to, with the at least one processor, cause the apparatus (see para [0136]-[0137] and Fig 1 showing equivalent computer functionality) to at least: receive a contextualized support ticket visualization request from a support provider computing device, wherein the contextualized support ticket visualization request comprises support ticket identifying metadata ("Systems and methods for enabling a person who is experiencing and interacting in a virtual environment to obtain customer support or other form of assistance within the environment for an object, service, or experience they interact with in the virtual environment. In some embodiments, this may include the option of obtaining support or a form of assistance from avatars or objects in the virtual environment. In one embodiment, this may be enabled by converting or transforming a request for assistance into an object (referred to as a support request object herein) in the virtual environment." and see para [0102]-[0113], showing metadata used in the requests and see para [0161], "In some embodiments, to provide “contextual” based customer support in a virtual world for a virtual product or virtual service may involve implementation of one or more of the following functions or capabilities:");
access a support ticket data object from a ticket-based service managing system based at least in part on the support ticket identifying metadata, wherein the support ticket data object comprises support seeker identifying metadata (Fig 1B showing the request for assistance is transferred to the support provider entity and see para [0101]-[0113], showing metadata includes metadata for establishing privileges with the product for which assistance is requested);
access a support seeker data object from an asset-based data tracking system based at least in part on the support seeker identifying metadata; (Fig 1B showing the request for assistance is transferred to the support provider entity and see para [0101]-[0113], showing metadata includes metadata for establishing privileges with the product for which assistance is requested); and
cause generating a contextualized support ticket user interface on the support provider computing device, wherein the contextualized support ticket user interface comprises a support seeker context user interface component (see para [0191], "In some embodiments, one or more of the modules used to determine if support is needed (or the customer support module) may generate a user interface 109 within the virtual or augmented reality environment to enable avatar 103 to interact with customer support services. Interface 109 may include selectable or activatable elements that avatar 103 may use to indicate a product (such as by model or generic category) or type of service for which assistance is desired, the type of assistance desired, or another aspect of a service request." where it is obvious to one of ordinary skill in the art that user interface generated in a virtual or augment augmented environment that provides customer support can be considered contextual based on the environment and see para [0161], "In some embodiments, to provide “contextual” based customer support in a virtual world for a virtual product or virtual service may involve implementation of one or more of the following functions or capabilities").
Ashby does not explicitly disclose wherein the support seeker data object comprises product and service context metadata. In analogous art, Murthi discloses the following limitations:
wherein the support seeker data object comprises product and service context metadata (see para [0016], "A modeling framework enables a client to obtain a more comprehensive and customer-centric health score, which may be used to pursue multiple objectives such as minimizing customer account escalation and churn risk and maximizing the rate of renewal and the probability of up sell. The modeling framework can ingest customer support ticket data, on behalf of a client, from various Customer Relationship Management (CRM) systems, such as Salesforce, Zendesk, etc. Data from support tickets, which may be referred to as cases, includes a detailed conversational log between a customer and a customer support agent intended to address product, Information Technology, and other technical issues that a customer is facing while using the client's product and/or service, in addition to including a plethora of case metadata. In order to get a comprehensive evaluation of customer health at any point in time, the modeling framework can use a multi-factor approach, basing the customer health score on deriving selected case factors such as customer sentiment, critical cases, complex cases, escalated cases, time to close cases, and the number of cases for a customer.");
wherein the contextualized support ticket user interface comprises a support seeker context user interface component based at least in part on the product and service context metadata, wherein the support seeker context user interface component comprises a product and service context metadata user interface element wherein the product and service context metadata user interface element comprises a service health and incidents metadata portion indicating health and incident status of one or more services associated with the support seeker identifying metadata (see para [0002], "Customer health is a metric that is used to measure the well-being of a customer's relationship with a client whose product and/or services are being used or consumed by the customer." and see para [0015]-[0019], showing health generated for the customer associated with a product and service and where the various conversation log entries can be considered equivalent to incidents given broadest reasonable interpretation and see para [0046], "The customer health score calculated using equation (8) produces a number on a scale between 0 and 100. Scores on the lower end of this scale which are closer to 0 indicate “Bad” customer health, while those scores which are closer to 100 indicate “Good” customer health. The customer support score offering on its user interface surfaces both a numeric value as well as a label (“Bad”, “Fair” or “Good”) that clients can use to take a number of actions related to the customer account depending on their specific use case. Some examples of such use cases are to make decisions on whether to escalate or de-escalate a customer account or a customer support ticket, to assess whether a customer account is going to churn, to assess the overall customer health that can provide insights into customer account renewal or up-sell opportunities, and the identification of negative trends in customer interactions over time via sentiment score trends and proactively identify a wellness path moving forward.")
It would have been obvious to a person of ordinary skill in the art at the time the invention was made to combine the teachings of Ashby with Murthi because wherein the support seeker data object comprises product and service context metadata enables more effective understanding of a customer's satisfaction with a product (see Murthi, para [0005]-[0009]).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the system for determining customer health scores as taught by Murthi in the system for providing decentralized support services in a virtual environment as taught by Ashby since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claims 2, 9 and 16:
Further, Ashby discloses the following limitations:
wherein the contextualized support ticket user interface comprises a support ticket description user interface component displayed adjacent to the support seeker context user interface component (see para [0305], "As noted, FIG. 5 is a diagram illustrating additional details of the elements or components 500 of a multi-tenant distributed computing service platform, in which an embodiment may be implemented. The example architecture includes a user interface layer or tier 502 having one or more user interfaces 503. Examples of such user interfaces include graphical user interfaces and application programming interfaces (APIs). Each user interface may include one or more interface elements 504. For example, users may interact with interface elements to access functionality and/or data provided by application and/or data storage layers of the example architecture. Examples of graphical user interface elements include buttons, menus, checkboxes, drop-down lists, scrollbars, sliders, spinners, text boxes, icons, labels, progress bars, status bars, toolbars, windows, hyperlinks, and dialog boxes. Application programming interfaces may be local or remote and may include interface elements such as a variety of controls, parameterized procedure calls, programmatic objects, and messaging protocols." and Fig 5, showing adjacent elements which includes text boxes and see para [0033]-[0038], "other sources of support or assistance may include sources of data, information, advice, or access to other information or systems; The sources of data, information, or advice may reside within or outside of the virtual environment); In one embodiment, conversion of a request into an object in the virtual environment provides a mechanism for transfer of information or data related to the request in a secure manner between avatars or objects within the virtual environment and/or sources of assistance outside of the virtual environment; In one embodiment, data and information related to or relevant to the request (such as regarding the requester, the state of the product or service for which assistance is being requested, or the environment around the product or service) may be stored on a blockchain and/or associated with a non-fungible token (NFT), or other form of token; The stored data and information may include data that may be used to verify the identity of the avatar and/or the person controlling the avatar, along with an indication of the rights or privileges of the avatar and/or person as those relate to the product or service for which assistance is being requested")
Claims 3-4, 10-11, 17-18:
Further, Ashby discloses the following limitations:
wherein the support seeker data object comprises customer context metadata (see para [0104]-[0105], "data, information, or metadata regarding the requesting avatar and/or person in control of the avatar—this data may be used to verify the identity of the requester and establish their rights and privileges with regards to the product or service for which assistance is requested; data, information, or metadata regarding the product or service for which assistance is requested")
wherein the support seeker context user interface component comprises a customer context metadata user interface element based at least in part on the customer context metadata (see para [0104]-[0105], where metadata establishing rights with a product can be considered based on from the seeker interface and based on customer context/license)
Claims 5-7, 12-14, 18-19:
Further, Ashby discloses the following limitations:
wherein the at least one non-transitory memory and the program code are configured to, with the at least one processor, cause the apparatus to: receive a support seeker organization visualization request from the support provider computing device, wherein the support seeker organization visualization request comprises support provider identifying metadata indicating that a support provider associated with the support provider computing device is allocated to an organization associated with the support seeker organization visualization request ("Systems and methods for enabling a person who is experiencing and interacting in a virtual environment to obtain customer support or other form of assistance within the environment for an object, service, or experience they interact with in the virtual environment. In some embodiments, this may include the option of obtaining support or a form of assistance from avatars or objects in the virtual environment. In one embodiment, this may be enabled by converting or transforming a request for assistance into an object (referred to as a support request object herein) in the virtual environment." and see para [0102]-[0113], showing metadata used in the requests");
access one or more support seeker data objects from the asset-based data tracking system based at least in part on the support provider identifying metadata (Fig 1B showing the request for assistance is transferred to the support provider entity and see para [0101]-[0113], showing metadata includes metadata for establishing privileges with the product for which assistance is requested); and
cause generating a support seeker organization overview user interface on the support provider computing device based at least in part on one or more support seeker data objects associated with the one or more services (see para [0191], "In some embodiments, one or more of the modules used to determine if support is needed (or the customer support module) may generate a user interface 109 within the virtual or augmented reality environment to enable avatar 103 to interact with customer support services. Interface 109 may include selectable or activatable elements that avatar 103 may use to indicate a product (such as by model or generic category) or type of service for which assistance is desired, the type of assistance desired, or another aspect of a service request." where it is obvious to one of ordinary skill in the art that user interface generated in a virtual or augment augmented environment that provides customer support can be considered contextual based on the environment and see para [0161], "In some embodiments, to provide “contextual” based customer support in a virtual world for a virtual product or virtual service may involve implementation of one or more of the following functions or capabilities")
wherein the support seeker organization overview user interface comprises an organization tabular user interface component (Figs 1, 5, showing UI elements can be organized in a tabular way and see para [0305], “Examples of graphical user interface elements include buttons, menus, checkboxes, drop-down lists, scrollbars, sliders, spinners, text boxes, icons, labels, progress bars, status bars, toolbars, windows, hyperlinks, and dialog boxes. Application programming interfaces may be local or remote and may include interface elements such as a variety of controls, parameterized procedure calls, programmatic objects, and messaging protocols.”)
wherein the at least one non-transitory memory and the program code are configured to, with the at least one processor, cause the apparatus to: receive a support seeker contact visualization request from the support provider computing device, wherein the support seeker contact visualization request comprises support provider identifying metadata ("Systems and methods for enabling a person who is experiencing and interacting in a virtual environment to obtain customer support or other form of assistance within the environment for an object, service, or experience they interact with in the virtual environment. In some embodiments, this may include the option of obtaining support or a form of assistance from avatars or objects in the virtual environment. In one embodiment, this may be enabled by converting or transforming a request for assistance into an object (referred to as a support request object herein) in the virtual environment." and see para [0102]-[0113], showing metadata used in the requests");
access one or more support seeker data objects from the asset-based data tracking system based at least in part on the support provider identifying metadata (Fig 1B showing the request for assistance is transferred to the support provider entity and see para [0101]-[0113], showing metadata includes metadata for establishing privileges with the product for which assistance is requested); and
cause generating a support seeker contact overview user interface on the support provider computing device based at least in part on the one or more support seeker data objects (Figs 1, 5, showing UI elements can be organized in a tabular way and see para [0305], “Examples of graphical user interface elements include buttons, menus, checkboxes, drop-down lists, scrollbars, sliders, spinners, text boxes, icons, labels, progress bars, status bars, toolbars, windows, hyperlinks, and dialog boxes. Application programming interfaces may be local or remote and may include interface elements such as a variety of controls, parameterized procedure calls, programmatic objects, and messaging protocols.”).
Claim 21:
Ashby does not explicitly disclose wherein the product and service context metadata user interface element comprises an upcoming service changes metadata portion indicating one or more upcoming service changes with the one or more service although Murthy shows this would be obvious based on how a trigger where the service is changed generates a service reqest (see para [0192], "As suggested by the “trigger” element in the figure, in some embodiments, a service request may be generated automatically in response to a situation or event. For example, an error message, an avatar performing a specific action or going to a specific place, or an object representing a product or service changing its appearance may be a form of trigger and may indicate that assistance is needed. In some embodiments, such a trigger may automatically generate a service request or ticket." and see para [0218], [0228]). In analogous art, Murthi discloses the following limitations:
wherein the product and service context metadata user interface element comprises an upcoming service changes metadata portion indicating one or more upcoming service changes with the one or more service (see para [0016]-[0018], where escalating and add resources can be considered a service change given broadest reasonable interpretation and see para [0070], "Each of the factors can correspond to a value associated with a time in one of the support tickets and can also correspond to a change in values associated with a current time and a preceding time in the one of the support tickets. For example, the machine-learning model 232 computes an absolute count of 8 Acme support tickets that have been escalated, and a trend which is a decrease by 7.5% in the rate of escalated Acme support tickets based on the previous rate of 10% escalated support tickets (10 of the 100 Acme support tickets had been escalated) and the current rate of 2.5% escalated support tickets (2 of the 80 Acme support tickets have been escalated).")
It would have been obvious to one of ordinary skill in the art at the time of the invention to include the system for determining customer health scores as taught by Murthi in the system for providing decentralized support services in a virtual environment as taught by Ashby since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jellen (US 2025/0209063 A1), a method for vector embedding of service incident data by receiving service incident data includes free-form text data, structured metadata, and human-generated comments, constructing a graph representation of a service incident, the graph includes nodes representing the free-form text data, structured metadata, and human-generated comments of the service incident, and edges connecting related nodes, generating vector embeddings for the nodes and edges of the graph representation, applying dimensionality reduction to the vector embeddings to generate reduced embeddings, and storing the reduced embeddings and the vector embeddings in a database
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUJAY KONERU whose telephone number is (571)270-3409. The examiner can normally be reached M-F, 8:30 AM to 5 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patricia Munson can be reached on 571- 270-5396. 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.
/SUJAY KONERU/
Primary Examiner, Art Unit 3624
Prosecution Insights