DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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. The applicant's submission, the “Amendment Under 37 C.F.R. § 1.116” of 01 July 2025 (hereinafter referred to as the “Amendment”), has been entered.
Status of the Claims
The pending claims in the present application are claims 1-20 of the Amendment.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The paragraphs below provide rationales for the rejection. The rationales are based on the multi-step subject matter eligibility test outlined in MPEP 2106.
Step 1 of the eligibility analysis involves determining whether a claim falls within one of the four enumerated categories of patentable subject matter recited in 35 USC 101. (See MPEP 2106.03(I).) That is, Step 1 asks whether a claim is to a process, machine, manufacture, or composition of matter. (See MPEP 2106.03(II).) Referring to the pending claims, the “method” of claims 1-7 constitutes a process under 35 USC 101, the “system” of claims 8-14 constitutes a machine under the statute, and the “non-transitory computer-readable recording medium” of claims 15-20 constitutes a manufacture under the statute. Accordingly, claims 1-20 meet the criteria of Step 1 of the eligibility analysis. The claims, however, fail to meet the criteria of subsequent steps of the eligibility analysis, as explained in the paragraphs below.
The next step of the eligibility analysis, Step 2A, involves determining whether a claim is directed to a judicial exception. (See MPEP 2106.04(II).) This step asks whether a claim is directed to a law of nature, a natural phenomenon (product of nature) or an abstract idea. (See id.) Step 2A is a two-prong inquiry. (See MPEP 2106.04(II)(A).) Prong One and Prong Two are addressed below.
In the context of Step 2A of the eligibility analysis, Prong One asks whether a claim recites an abstract idea, law of nature, or natural phenomenon. (See MPEP 2106.04(II)(A)(1).) Using independent claim 1 as an example, the claim recites the following abstract idea limitations:
“A method of managing services via a centralized network platform, the method comprising: ...” - See below regarding MPEP 2106.04(a), certain methods of organizing human activity, and mental processes
“... receiving ... a request from a user to create a new ticket family, wherein each ticket family includes linked families having multiple workflows mapped to certain domains and categories; ...” - See below regarding MPEP 2106.04(a), certain methods of organizing human activity, and mental processes
“... based on a first user input to create a first ticket family, creating the ticket family, wherein the first ticket family corresponds to a first process; ...” - See below regarding MPEP 2106.04(a), certain methods of organizing human activity, and mental processes
“... based on a second user input to configure a first view, creating the first view comprising one or more first user input fields for capturing ticket information for the first ticket family; ...” - See below regarding MPEP 2106.04(a), certain methods of organizing human activity, and mental processes
“... based on a third user input to create a second ticket family, creating the second ticket family, wherein the second ticket family corresponds to a second process; ...” - See below regarding MPEP 2106.04(a), certain methods of organizing human activity, and mental processes
“... based on a fourth user input to configure a second view, creating the second view comprising one or more second user input fields for capturing ticket information for the second ticket family; and ...” - See below regarding MPEP 2106.04(a), certain methods of organizing human activity, and mental processes
“... based on a fifth user input to configure a first workflow for the first ticket family or the second ticket family, creating the first workflow, the first workflow including the first view and the first workflow mapped to at least one of a first domain and a first category ...” - See below regarding MPEP 2106.04(a), certain methods of organizing human activity, and mental processes
“... receiving a selection of a domain ...” - See below regarding MPEP 2106.04(a), certain methods of organizing human activity, and mental processes
“... based on the selected domain, ... switching to a workflow and displaying views assigned to the selected domain.” - See below regarding MPEP 2106.04(a), certain methods of organizing human activity, and mental processes
The above-listed limitations of independent claim 1, when applying their broadest reasonable interpretations in light of their context in the claim as a whole, fall under enumerated groupings of abstract ideas outlined in MPEP 2106.04(a). For example, limitations of the claim can be characterized as: commercial interactions, including sales activities or behaviors associated with customer service); and managing personal behavior or relationships or interactions between people, associated with providing customers with service, which fall under the certain methods of organizing human activity grouping of abstract ideas (see MPEP 2106.04(a)). Limitations of the claim also can be characterized as: concepts performed in the human mind, including observation (e.g., the recited “receiving” steps), and evaluation, judgment, and/or opinion (e.g., the recited “based” steps), which fall under the mental processes grouping of abstract ideas (see MPEP 2106.04(a)). Accordingly, for at least these reasons, claim 1 fails to meet the criteria of Step 2A, Prong One of the eligibility analysis.
In the context of Step 2A of the eligibility analysis, Prong Two asks if the claim recites additional elements that integrate the judicial exception into a practical application. (See MPEP 2106.04(II)(A)(2).) Continuing to use independent claim 1 as an example, the claim recites the following additional element limitations:
The claimed “managing” is “via a centralized network platform” - See below regarding MPEP 2106.05(a)-(c) and (f)-(h)
The claimed “receiving” is performed “using graphical user interface (GUI) of a centralized network platform” - See below regarding MPEP 2106.05(a)-(c) and (f)-(h)
The claimed “first category” is “configured via the centralized network platform” - See below regarding MPEP 2106.05(a)-(c) and (f)-(h)
The claimed “receiving” is “from the GUI” - See below regarding MPEP 2106.05(a)-(c) and (f)-(h)
The claimed “switching” is performed “automatically” - See below regarding MPEP 2106.05(a)-(c) and (f)-(h)
The above-listed additional element limitations of independent claim 1, when applying their broadest reasonable interpretations in light of their context in the claim as a whole, are analogous to: accelerating a process of analyzing audit log data when the increased speed comes solely from the capabilities of a general-purpose computer, and mere automation of manual processes, which courts have indicated may not be sufficient to show an improvement in computer-functionality (see MPEP 2106.05(a)(I)); a commonplace business method being applied on a general purpose computer, gathering and analyzing information using conventional techniques and displaying the result, and selecting a particular generic function for computer hardware to perform from within a range of fundamental or commonplace functions performed by the hardware, which courts have indicated may not be sufficient to show an improvement to technology (see MPEP 2106.05(a)(II)); a general purpose computer that applies a judicial exception, such as an abstract idea, by use of conventional computer functions, and merely adding a generic computer, generic computer components, or a programmed computer to perform generic computer functions, which do not qualify as a particular machine or use thereof (see MPEP 2106.05(b)(I)); a machine that is merely an object on which the method operates, which does not integrate the exception into a practical application (see MPEP 2106.05(b)(II)); use of a machine that contributes only nominally or insignificantly to the execution of the claimed method, which does not integrate a judicial exception (see MPEP 2106.05(b)(III)); transformation of an intangible concept such as a contractual obligation or mental judgment, which is not likely to provide significantly more (see MPEP 2106.05(c)); remotely accessing user-specific information through a mobile interface and pointers to retrieve the information without any description of how the mobile interface and pointers accomplish the result of retrieving previously inaccessible information, which courts have found to be mere instructions to apply an exception, because they recite no more than an idea of a solution or outcome (see MPEP 2106.05(f)); use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea, a commonplace business method or mathematical algorithm being applied on a general purpose computer, and requiring the use of software to tailor information and provide it to the user on a generic computer, which courts have found to be mere instructions to apply an exception, because they do no more than merely invoke computers or machinery as a tool to perform an existing process (see MPEP 2106.05(f)); mere data gathering in the form of obtaining information about transactions using the Internet to verify transactions and consulting and updating an activity log, which courts have found to be insignificant extra-solution activity (see MPEP 2106.05(g)); and specifying that the abstract idea of monitoring audit log data relates to transactions or activities that are executed in a computer environment, because this requirement merely limits the claims to the computer field, i.e., to execution on a generic computer, which courts have described as merely indicating a field of use or technological environment in which to apply a judicial exception (see MPEP 2106.05(h)). For at least these reasons, claim 1 fails to meet the criteria of Step 2A, Prong Two of the eligibility analysis.
The next step of the eligibility analysis, Step 2B, asks whether a claim recites additional elements that amount to significantly more than the judicial exception. (See MPEP 2106.05(II).) The step involves identifying whether there are any additional elements in the claim beyond the judicial exceptions, and evaluating those additional elements individually and in combination to determine whether they contribute an inventive concept. (See id.) The ineligibility rationales applied at Step 2A, Prong Two, also apply to Step 2B. (See id.) For all of the reasons covered in the analysis performed at Step 2A, Prong Two, independent claim 1 fails to meet the criteria of Step 2B. Further, claim 1 also fails to meet the criteria of Step 2B because at least some of the additional elements are analogous to: receiving or transmitting data over a network, e.g., using the Internet to gather data, which courts have recognized as well-understood, routine, conventional activity, and as insignificant extra-solution activity (see MPEP 2106.05(d)(II)). As a result, claim 1 is rejected under 35 USC 101 as ineligible for patenting.
Regarding pending claims 2-7, the claims depend from independent claim 1, and expand upon limitations introduced by claim 1. The dependent claims are rejected at least for the same reasons as claim 1. For example, the dependent claims recite abstract idea elements similar to the abstract idea elements of claim 1, that fall under the same abstract idea groupings as the abstract idea elements of claim 1 (e.g., the “further comprising: based on a sixth user input to configure a second view, creating the second view comprising one or more second user input fields for capturing ticket information; and based on a seventh user input to configure a second workflow for the first ticket family, creating the second workflow, the second workflow including the second view and the second workflow mapped to at least one of a second domain and a second category configured” of claim 2, the “further comprising: based on receiving an eighth user input to select the first ticket family for creating a new ticket of the first ticket family, outputting ...; receiving a ninth user input ... for selecting at least one of a domain and a category for the new ticket; outputting the first view according to the first workflow, based on the ninth user input selecting the first domain or the first category; and outputting the second view according to the second workflow, based on the ninth user input selecting the second domain or the second category” of claim 3, the “wherein the first user input comprises at least one of a ticket family name and a ticket family description for the first ticket family” of claim 4, the “wherein the fifth user input comprises a user selection of the first ticket family or the second ticket family” of claim 5, the “further comprising creating the first domain based on a ninth user input to create the first domain and select the first ticket family or the second ticket family to which to associate the first domain” of claim 6, and the “further comprising creating the first category based on an tenth user input to create the first category and select the first ticket family or the second ticket family to which to associate the first category” of claim 7). The dependent claims recite further additional elements that are similar to the additional elements of claim 1, that fail to warrant eligibility for the same reasons as the additional elements of claim 1 (e.g., the “via the centralized network platform” of claim 2), and for other reasons, including instructions to display two sets of information on a computer display in a non-interfering manner, without any limitations specifying how to achieve the desired result, and arranging transactional information on a graphical user interface in a manner that assists traders in processing information more quickly, which courts have indicated may not be sufficient to show an improvement in computer-functionality (see MPEP 2106.05(a)(I)), and requiring the use of software to tailor information and provide it to the user on a generic computer, which courts have found to be mere instructions to apply an exception, because they do no more than merely invoke computers or machinery as a tool to perform an existing process (see MPEP 2106.05(f)) (e.g., the “a user interface screen ... to the user interface screen” of claim 3). Accordingly, claims 2-7 also are rejected as ineligible under 35 USC 101.
Regarding pending claims 8-14, while the claims are of different scope relative to claims 1-7, the claims recite limitations similar to the limitations of claims 1-7. As such, the rejection rationales applied to reject claims 1-7 also apply for purposes of rejecting claims 8-14. Limitations recited by claims 8-14 that do not have a counterpart in claims 1-7, such as the recited hardware limitations of independent claim 8, fail to warrant a finding of eligibility, because such limitations amount to additional elements that fail to meet the criteria of Step 2A, Prong Two and Step 2B, for the same reasons as the additional elements of claims 1-7. Claims 8-14 are, therefore, also rejected as ineligible under 35 USC 101.
Regarding pending claims 15-20, while the claims are of different scope relative to claims 1-14, the claims recite limitations similar to the limitations of claims 1-14. As such, the rejection rationales applied to reject claims 1-14 also apply for purposes of rejecting claims 15-20. Claims 15-20 are, therefore, also rejected as ineligible under 35 USC 101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Pat. No. 10,505,825 B1 to Bettaiah et al. (hereinafter referred to as “Bettaiah”).
Regarding independent claim 1, Bettaiah discloses the following limitations:
“A method of managing services via a centralized network platform, the method comprising: ...” - Bettaiah discloses, “The operation of an automatic service monitoring system (SMS) is directed by stored control information. Methods and mechanisms are provided to create control information that directs operations of the SMS regarding the grouping together of related notable events for unified display and processing. The control information directs grouping operations that automatically correlate the events without requiring, for example, a set of declarative grouping rules” (Abstract), and “These challenges can be addressed by using an event-based system, such as the SPLUNK® ENTERPRISE system produced by Splunk Inc. of San Francisco, Calif., to store and process performance data. The SPLUNK® ENTERPRISE system is the leading platform for providing real-time operational intelligence that enables organizations to collect, index, and harness machine-generated data from various web sites, applications, servers, networks, and mobile devices that power their businesses” (col. 378, ll. 32-40). The methodology for service monitoring via the automatic service monitoring system of the Splunk Enterprise system, in Bettaiah, reads on the recited limitation.
“... receiving, using graphical user interface (GUI) of a centralized network platform, a request from a user to create a new ticket family, wherein each ticket family includes linked families having multiple workflows mapped to certain domains and categories; ...” - See the aspects of Bettaiah that have been cited above. Bettaiah also discloses, “FIG. 34U illustrates an example of a GUI for configuring a ServiceNow™ incident ticket produced as a result of a correlation search, in accordance with one or more implementations of the present disclosure. In one implementation, GUI 34700 accepts user input to configure the creation a ticket in an incident ticketing system as the action resulting from the data produced by a correlation search query satisfying the associated triggering condition. In one implementation, the system may create a ticket in the ServiceNow™ incident ticketing system. In other implementations, other incident ticketing or service management systems may be used. The generated ticket serves as a record of the incident or event that triggered the correlation search and can be used to track analysis and service of the incident or event” (col. 197, l. 63 to col. 198, l. 9), “Ticket type field 34701 receives input to specify the whether the ticket type is an incident or an event” (col. 198, ll. 12-14), “FIG. 34ZD2 depicts a user interface related to group membership criteria for an event group in one embodiment. Such an interface may be used in an embodiment to prompt for and acquire user input indicating the desired content for an event group policy being created (or edited), and particularly information of the event group policy definition related to identifying events as members of the event group” (col. 228, ll. 53-59), and “FIG. 34ZD8 depicts a user interface related to event group policies. Such an interface may be useful in relation to the command console and reporting processing block 90836 of FIG. 34ZD1. The user interface display 91500 is shown to include system title bar area 90902, application menu/navigation bar area 90904, application header area 91510, event group policy list area 91520, and “Create New Policy” action button 91590. Application header area 91510 is shown to include the title “Aggregation Policy” indicative of the usefulness of the event group policy definitions and processing, thereof and thereby, to aggregate or consolidate multiple individual events, such as notable events, under a representative group identification and affiliation” (col. 235, ll. 28-40). Receiving, using the GUI of the SMS, user inputs for tickets for events to be grouped by event group policies, wherein each event group policy includes group identifications and affiliations (including severity, status, and description information, per FIG. 34ZD9), in Bettaiah, reads on the recited limitation.
“... based on a first user input to create a first ticket family, creating the ticket family, wherein the first ticket family corresponds to a first process; ...” - See the aspects of Bettaiah that have been cited above. Based on user inputs for creating event groups, creating the event groups, wherein the event groups correspond to service events, in Bettaiah, reads on the recited limitation.
“... based on a second user input to configure a first view, creating the first view comprising one or more first user input fields for capturing ticket information for the first ticket family; ...” - See the aspects of Bettaiah that have been cited above. Bettaiah also discloses, “FIG. 52 illustrates an example GUI 5200 for adding a graphical visualization of KPI values along a time-based graph lane to a visual interface, in accordance with one or more implementations of the present disclosure. In one implementation, in response to the creation of a visual interface using GUI 5100, the system presents GUI 5200 in order to add graphical visualizations to the visual interface. The graphical visualizations correspond to KPIs and are displayed along a time-based graph lane in the visual interface” (col. 303, ll. 20-26), “In one example, GUI 5200 can receive user input for a number of input fields 5202, 5204, 5212, selections from drop down menus 5206, 5208, and/or selection of selection buttons 5210 or link 5214. For example, input field 5202 can receive a title for the graphical visualization being added. Input field 5204 may receive a subtitle or description of the graphical visualization” (col. 303, ll. 30-36), and “FIG. 68B illustrates an example of a visual interface displaying an event graph lane with event information in an additional lane, in accordance with one or more implementations of the present disclosure. In one implementation, time-based graph lane 6810, is an event lane having a visual representation of the number of events occurring over a given period of time” (col. 315, ll. 14-20). Based on the prompted user inputs for generating graphical visualizations, the graphic visualizations including GUIs for receiving user inputs via input fields for information about tickets for events aggregated into various groups, in Bettaiah, reads on the recited limitation.
“... based on a third user input to create a second ticket family, creating the second ticket family, wherein the second ticket family corresponds to a second process; ...” - See the aspects of Bettaiah that have been cited above. Based on user inputs for creating other event groups, creating the other event groups, wherein the other event groups correspond to other service events, in Bettaiah, reads on the recited limitation.
“... based on a fourth user input to configure a second view, creating the second view comprising one or more second user input fields for capturing ticket information for the second ticket family; and ...” - See the aspects of Bettaiah that have been cited above. Based on the other prompted user inputs for generating other graphical visualizations, the other graphic visualizations including other GUIs for receiving other user inputs via other input fields for information about other tickets for other events aggregated into various other groups, in Bettaiah, reads on the recited limitation.
“... based on a fifth user input to configure a first workflow for the first ticket family or the second ticket family, creating the first workflow, the first workflow including the first view and the first workflow mapped to at least one of a first domain and a first category configured via the centralized network platform; ...” - See the aspects of Bettaiah that have been cited above. Receiving user inputs for automatically generating the graphical visualizations, with lanes for and about the events, and with input windows with fields used to dictate aspects of the graphical visualizations, for events of certain types, using the SMS, in Bettaiah, reads on the recited limitation.
“... receiving a selection of a domain from the GUI; and ...” - See the aspects of Bettaiah that have been cited above. Receiving user inputs into input fields of the graphical visualizations, wherein the inputs focus on events of specific types, in Bettaiah, reads on the recited limitation.
“... based on the selected domain, automatically switching to a workflow and displaying views assigned to the selected domain.” - See the aspects of Bettaiah that have been cited above. Based on the user inputs, the SMS implementing steps to generate graphical visualizations and other windows based thereon, in Bettaiah, reads on the recited limitation.
Regarding claim 2, Bettaiah discloses the following limitations:
“The method of claim 1, further comprising: based on a sixth user input to configure a second view, creating the second view comprising one or more second user input fields for capturing ticket information; and ...” - See the aspects of Bettaiah that have been cited above. Based on yet another prompted user input for generating yet another graphical visualization, the yet another graphic visualization including yet another GUI for receiving yet another user input via yet other input field for information about yet another ticket for yet another event aggregated into yet another group, in Bettaiah, reads on the recited limitation.
“... based on a seventh user input to configure a second workflow for the first ticket family, creating the second workflow, the second workflow including the second view and the second workflow mapped to at least one of a second domain and a second category configured via the centralized network platform.” - See the aspects of Bettaiah that have been cited above. Receiving other user inputs for automatically generating other graphical visualizations, with other lanes for and about other events, and with other input windows with other fields used to dictate aspects of the other graphical visualizations, for other events of certain types, using the SMS, in Bettaiah, reads on the recited limitation.
Regarding claim 3, Bettaiah discloses the following limitations:
“The method of claim 2, further comprising: based on receiving an eighth user input to select the first ticket family for creating a new ticket of the first ticket family, outputting a user interface screen; ...” - See the aspects of Bettaiah that have been cited above. Bettaiah also discloses, “FIG. 34U illustrates an example of a GUI for configuring a ServiceNow™ incident ticket produced as a result of a correlation search, in accordance with one or more implementations of the present disclosure. In one implementation, GUI 34700 accepts user input to configure the creation a ticket in an incident ticketing system as the action resulting from the data produced by a correlation search query satisfying the associated triggering condition” (col. 197, l. 63 to col. 198, l. 3), and “In one implementation, GUI 34700 may include a number of user input fields that receive user input to configure creation of the ticket. Ticket type field 34701 receives input to specify the whether the ticket type is an incident or an event. When the ticket type is set as “incident,” fields 34702-34706 are displayed. Category field 34702 receives input to specify whether the ticket should be categorized as a request, inquiry, software related, hardware related, network related, or database related. Contact type field 34703 receives input to specify whether the ticket was created as a result of an email, a phone call, self-service request, walk-in, form or forms. Urgency field 34704 receives input to specify whether an urgency for the ticket should be set as low, medium or high. State field 34705 receives user input to specify whether an initial state of the ticket should be set as new, active, awaiting problem, awaiting user information, awaiting evidence, resolved or closed. Description field 34706 receives textual input specifying any other information related to the ticket that is not included above” (col. 198, ll. 10-28). Based on receiving additional user inputs to facilitate putting tickets for events into groups, outputting the GUI, in Bettaiah, reads on the recited limitation.
“... receiving a ninth user input, to the user interface screen, for selecting at least one of a domain and a category for the new ticket; ...” - See the aspects of Bettaiah that have been cited above. Selecting categories, types, and similar information for tickets using the GUI, in Bettaiah (see FIG. 34U), reads on the recited limitation.
“... outputting the first view according to the first workflow, based on the ninth user input selecting the first domain or the first category; and ...” - See the aspects of Bettaiah that have been cited above. The category, type, and other ticket information input by the user being used to generate the downstream graphical visualization, in Bettaiah, reads on the recited limitation.
“... outputting the second view according to the second workflow, based on the ninth user input selecting the second domain or the second category.” - See the aspects of Bettaiah that have been cited above. The other category, other type, and other ticket information input by the user being used generate the other downstream graphical visualization, in Bettaiah, reads on the recited limitation.
Regarding claim 4, Bettaiah discloses the following limitations:
“The method of claim 1, wherein the first user input comprises at least one of a ticket family name and a ticket family description for the first ticket family.” - See the aspects of Bettaiah that have been cited above. The user input including the ticket type, category, contact type, urgency, state, and description information, for use in grouping the ticket, in Bettaiah (see FIG. 34U), reads on the recited limitation.
Regarding claim 5, Bettaiah discloses the following limitations:
“The method of claim 1, wherein the fifth user input comprises a user selection of the first ticket family or the second ticket family.” - See the aspects of Bettaiah that have been cited above. The user input including category information, or other information, thereby putting the ticket into one grouping or another, in Bettaiah (see FIG. 34 U), reads on the recited limitation.
Regarding claim 6, Bettaiah discloses the following limitations:
“The method of claim 1, further comprising creating the first domain based on a ninth user input to create the first domain and select the first ticket family or the second ticket family to which to associate the first domain.” - See the aspects of Bettaiah that have been cited above. Creating the group based on user inputs to create the group (via, e.g., setting group policies or rules), and putting the tickets into categories leading them to be placed into one group or another, in Bettaiah, reads on the recited limitation.
Regarding claim 7, Bettaiah discloses the following limitations:
“The method of claim 1, further comprising creating the first category based on an tenth user input to create the first category and select the first ticket family or the second ticket family to which to associate the first category.” - See the aspects of Bettaiah that have been cited above. Creating the group based on user inputs to create the group (via, e.g., setting group policies or rules), and putting the tickets into categories leading them to be placed into one group or another, in Bettaiah, reads on the recited limitation.
Regarding claims 8-14, while the claims are of different scope relative to claims 1-7, the claims recite limitations similar to those recited by claims 1-7. As such, the rationales applied to reject claims 1-7 also apply for purposes of rejecting claims 8-14. Further, Bettaiah discloses elements that read on the recited hardware limitations of claims 8-14 (i.e., FIG. 83 of Bettaiah reads on the hardware limitations of independent claim 8). Claims 8-14 are, therefore, also rejected under 35 USC 102(a)(1) as anticipated by Bettaiah.
Regarding claims 15-20, while the claims are of different scope relative to claims 1-14, the claims recite limitations similar to those recited by claims 1-14. As such, the rationales applied to reject claims 1-14 also apply for purposes of rejecting claims 15-20. Claims 15-20 are, therefore, also rejected under 35 USC 102(a)(1) as anticipated by Bettaiah.
Response to Arguments
On pp. 11-13 of the Amendment, the applicant requests reconsideration and withdrawal of the claim rejection under 35 USC 101. Specifically, the applicant argues that the amended claims embody a technological improvement, and are therefore eligible. (See Amendment, p. 11.) More specifically, the applicant argues that the improved GUI somehow produces a platform that requires minimum energy consumption, is resource efficient, is less taxing on computing resources and network elements, and provides high customer satisfaction. (See id.) The applicant’s other arguments relate to these arguments. (See Amendment, pp. 12 and 13.) The examiner finds the arguments unpersuasive. There is no apparent connection between the GUI and the alleged technological improvements. The applicant would need to point out where in the disclosure there is discussion of the way in which content displayed on a GUI minimizes energy consumption, makes resources run more efficiently, or alleviates burdens on computing resources. The examiner contends that the claimed GUI would actually do the opposite. Further, providing high customer satisfaction is not a technological improvement. The claims remain rejected for ineligibility.
On pp. 13 and 14 of the Amendment, the applicant requests reconsideration and withdrawal of the claim rejection under 35 USC 102, based on the cited Shukla reference. The applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. The claims remain rejected due to anticipation.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THOMAS Y. HO, whose telephone number is (571)270-7918. The examiner can normally be reached Monday through Friday, 9:30 AM to 5:30 PM Eastern.
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, Jerry O'Connor, can be reached at 571-272-6787. 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.
/THOMAS YIH HO/Primary Examiner, Art Unit 3624