DETAILED ACTION
This Final Office Action is in response to Applicant's amendments and arguments filed on August 6, 2026. Applicant has amended claims 1, 8 and 15. 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 .
Response to Amendments
The 35 U.S.C. 101 rejections of claims 1-19, 21 are maintained in light of applicant’s amendment to claims 1, 8 and 15.
The 35 U.S.C. 103 rejections of claims 1-19, 21 are withdrawn in light of applicant’s amendment to claims 1, 8 and 15. Applicant’s amendments necessitated the new grounds for rejection in this office action.
Response to Arguments
Applicant’s remarks submitted on 8/6/26 have been considered but are not persuasive. Applicant argues on p. 8 of the remarks that the 103 rejections are improper. Applicant’s arguments are related to the amended language. These arguments are moot in light of the newly cited Titon reference. Applicant argues on p. 9 of the remarks that the 101 rejections are improper. Examiner disagrees. Applicant argues that the examiner has oversimplified the claims into a generalized concept. Examiner disagrees and notes the abstract idea is “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 accessing data indicating service outage associated with one or more services and generating a contextualized support ticket user” which is not a generalized concept. Moreover, the grouping as organizing human activity is appropriate in a proper two-part Alice-Mayo analysis. Applicant further argues that the claims are an improvement to technology. Examiner disagrees and notes the claims are an improvement to the abstract idea and the technology in the claims is considered generally linking the abstract idea to a computing environment and tools for implementing the abstract idea itself. Therefore, the 101 rejections are maintained.
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 accessing data indicating service outage associated with one or more services 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 accessing a service data object based on service identifying metadata associated with the product and service 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 the service outage associated with the one or more services 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 accessing a service data object based on service identifying metadata associated with the product and service 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 the service outage 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. 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) in view of Titon et al. (US 20240275699 A1) (hereinafter Titon).
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 (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.
Ashby and Murthi do not explicitly disclose wherein the service data object indicates service outage associated with one or more services. In analogous art, Titon discloses the following limitations:
access a service data object based on service identifying metadata associated with the product and service context metadata, wherein the service data object indicates service outage associated with one or more services (see para [0013], "This disclosure describes utilizing a service incident resolution system to quickly, efficiently, and accurately determine and mitigate service incidents in a cloud computing system. For example, based on identifying an outage ticket (e.g., a customer-impacting incident ticket), the service incident resolution system identifies the additional context of the outage by detecting a number of monitoring signals that relate to the outage. For instance, the service incident resolution system utilizes various monitoring signals and service models to determine one or more monitoring signals that are relevant to the outage ticket by efficiently selecting relevant monitoring signals and filtering out noisy ones. In this way, vaguely reported service incidents having sparse information are supplemented with information-rich monitoring signals that allow for these outages to be quickly resolved. Additionally, in some instances, the service incident resolution system utilizes service-based models to efficiently localize an outage based on determining which mitigation services or relevant mitigation teams are well-equipped to quickly address a reported service incident." and see para [0019], " In additional implementations, the service incident resolution system supplements the ranked list of relevant monitoring incident tickets with one or more relevant mitigation teams (e.g., mitigation services or teams that work to resolve the outage). For example, in various implementations, the service incident resolution system generates a list of relevant mitigation teams for the outage ticket (and/or corresponding monitoring service identifiers) utilizing a teams relationship graph generated by a mitigation teams relevancy model and the outage ticket. Additionally, the service incident resolution system generates the list of relevant mitigation teams, for example, by correlating tokenized text from text fields of the outage ticket with relevant mitigation teams in the teams relationship graph." and Figs 3-6)
wherein the product and service context metadata user interface element comprises a service health and incidents metadata portion indicating the service outage associated with the one or more services (see para [0019], " In additional implementations, the service incident resolution system supplements the ranked list of relevant monitoring incident tickets with one or more relevant mitigation teams (e.g., mitigation services or teams that work to resolve the outage). For example, in various implementations, the service incident resolution system generates a list of relevant mitigation teams for the outage ticket (and/or corresponding monitoring service identifiers) utilizing a teams relationship graph generated by a mitigation teams relevancy model and the outage ticket. Additionally, the service incident resolution system generates the list of relevant mitigation teams, for example, by correlating tokenized text from text fields of the outage ticket with relevant mitigation teams in the teams relationship graph." and see para [0061]-[0063], "To illustrate, FIG. 4 shows an example of applying service input conditions to incident tickets corresponding to an outage ticket in accordance with one or more implementations. FIG. 4 includes many of the components shown in FIG. 2; however, the service input conditions 208 have been expanded to include example acts. Indeed, FIG. 4 provides additional details regarding accessing the incident tickets data repository 204 to identify an initial set of monitoring incident tickets based on service input conditions 208, which are provided to the service incident monitoring model 210 for further processing to generate a ranked list of monitoring incident tickets 212. While the service input conditions 208 include a number of acts, the service incident resolution system 206 can add, omit, skip, and/or reorder the acts shown in the service input conditions 208. In general, the service incident resolution system 206 applies one or more sets of conditions, rules, and/or thresholds from the service input conditions 208 to incident tickets stored in the incident tickets data repository 204 to provide to the service incident monitoring model 210. For example, the service incident resolution system 206 utilizes a first set of conditions to generate a first set of incident tickets that serve as candidate requests that are important to the outage ticket 202 (e.g., the given outage ticket). As another example, the service incident resolution system 206 identifies a second set of incident tickets to help evaluate the first set (e.g., as a baseline or reference). Further, the service incident resolution system 206 can generate additional sets or subsets of incident tickets. As shown, the service input conditions 208 includes an act 402 of filtering monitoring incident tickets from the incident tickets data repository 204 by time (and/or date). For instance, the service incident resolution system 206 generates a first set of incident tickets by identifying one or more monitoring incident tickets that occur within a time period of the outage ticket 202. For example, based on a timestamp of the outage ticket 202, the service incident resolution system 206 filters in (e.g., identifies, selects) requests that occur within a time window, e.g., 30 mins (or another time window such as 15 seconds, 1 minute, 5 minutes, 1 hour, 1 day, 1 month, etc.) of the outage ticket 202. Often, the monitoring service generates several monitoring incident tickets for the same incident or outage event. As another example, the service incident resolution system 206 generates a second set of requests based on monitoring incident tickets within a second time window, such as 1-2 years. In some of these implementations, the second set excludes requests in the first set and/or does not overlap with the first set." and see para [0072], " As shown in FIG. 5, the service incident resolution system 206 provides outputs from the service input conditions 208 to the service incident monitoring model 210. For example, the service incident resolution system 206 provides one or more of the incident ticket sets determined by the service input conditions 208 to the service incident monitoring model 210 to generate the ranked list of monitoring incident tickets 212." and Figs 3-6)
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 and Murthi with Titon because integrating service outages provides a specific incident that is critical for users to mitigate (see Titon, para [0001]).
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 improving service incident mitigation as taught by Titon in the Ashby and Murthi combination 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.
Gugino et al. (US 2022/0100766 A1), a system for configured to receive a request to determine a state of maintenance availability of the cluster where each of the plurality of applications installed on the cluster are discoverable, and a deployment metadata associated with each of the plurality of applications is retrieved.
Halbe et al. (US 2024/0303611 A1), a method comparing a first RUL value to a service interval threshold; generating a near-term service recommendation including a first list of components that correspond to each RUL value that are less than or equal to the service interval threshold; generating an extended term service recommendation including a second list of components and a downtime prediction; generating a coordinated service recommendation by dynamically populating one or more fields of the coordinated service recommendation based on the near-term service recommendation and the extended term service recommendation; and providing the combined service recommendation to a user device
THIS ACTION IS MADE FINAL. 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 extension fee 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 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