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 .
This action is in response to response filed on 10/16/2025. This action is FINAL.
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.
Claim 1-5, 7-9, 11-20 and 22-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 1 recites, “creating a temporary issue entry” and “determining,… a first set of potentially duplicate originating issue entries…”. The limitations of “creating” and “determining” as drafted are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the function through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, this judicial exception is not integrated into a practical application. The claim recites the following additional elements “receiving…a request for submitting a new development issue”, “receiving… a first set of user-provided information…”, “storing the first set of user-provided information…” and “storing, in the originating issue database, the temporary issue entry as a new contribution sub-entry”. The additional elements of “receiving”, “receiving”, “storing” and “storing” are insignificant extra-solution activities. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception.
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “receiving…a request for submitting a new development issue”, “receiving… a first set of user-provided information…”, “storing the first set of user-provided information…” and “storing, in the originating issue database, the temporary issue entry as a new contribution sub-entry” as well-understood, routine, conventional activities. Storing and retrieving information in memory and receiving or transmitting data over a network are well-understood, routine, conventional activities (2106.05(d)). Accordingly, claim 1 is not patent eligible under 35 USC 101.
Claim 2, claims “receiving, from the first user” and “storing the supplementary set”. Storing and retrieving information in memory and receiving or transmitting data over a network are well-understood, routine, conventional activities (2106.05(d)). The claim further claims, “determining… an updated set of potentially duplicate originating issue entries”. This is an additional limitation of the abstract idea “Mental Process”. Nothing in the claimed limitations prevents this limitation from being performed in the mind. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 3, claims the additional limitation “storing, in the originating issue database, the temporary issue entry…”. Storing and retrieving information in memory are well-understood, routine, conventional activities (2106.05(d)). The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 4, claims the additional limitation “determining… an issue metric…”. This is an additional limitation of the abstract idea “Mental Process”. Nothing in the claimed limitations prevents this limitation from being performed in the mind. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 5, claims the additional limitation, “storing… the temporary issues entry…”. Storing and retrieving information in memory are well-understood, routine, conventional activities (2106.05(d)). The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 7, claims the additional limitations of “receiving… a for-contribution selection… and a request to make a contribution…”, “creating a contribution sub-entry” and “receiving and storing a set of for-contribution user-provided information”. Storing and retrieving information in memory are well-understood, routine, conventional activities (2106.05(d)). Creating a contribution sub-entry is an additional limitation of the abstract idea “Mental Process”. Nothing in the claimed limitations prevents this limitation from being performed in the mind. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 8, claims “… determining… an issue metric…”. This is an additional limitation of the abstract idea “Mental Process”. Nothing in the claimed limitations prevents this limitation from being performed in the mind. The additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claim 9, the additional elements are neither a practical application under prong 2, nor an inventive concept under step 2B.
Claims 11-20 and 22-24, claim similar limitations to claims 1-5 and 7-9 and are therefore rejected for the same reasons. Further the system, processor and memory of claim 11 and the platform and database of claim 19 amounts to additional elements that are generic computing components and would not (when considered individually or as a combination) amount to a practical application of the abstract idea or amount to significantly more.
Claim Rejections - 35 USC § 103
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.
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.
Claims 1-5, 7-9, 11-20 and 22-24 are rejected under 35 U.S.C. 103 as being unpatentable over Siconolfi et al. (US 10,489,728 B1) and further in view of Burton et al. (US 2019/0026697 A1).
As per claim 1, Siconolfi et al. teaches the invention as claimed including, “A method for tracking of issues in a software development process, the method comprising:
receiving, from a first user, a request for submitting a new development issue;
in response to the request, creating a temporary issue entry;
receiving, from the first user, a first set of user-provided information pertaining to the new development issue;
storing the first set of user-provided information within the temporary issue entry;”
Siconolfi et al. teaches if a user encounters a problem, the user can report the problem by generating an indication of the problem. The user can generate a problem ticket, where the problem ticket describes the presence if the problem and describes characteristics of the problem (column 3, lines 35-41). Also see column 4, lines 38-53). Upon generating the problem ticket, the use can submit information to fill some required fields of the problem ticket (column 6, lines 57-65). The problem ticket can be published to allow collaboration (column 3, lines 20-35). The examiner states that it is inherent that the problem ticket is stored in some time of memory and that the problem ticket is temporary until it is published for collaboration. Siconolfi et al. further teaches, a problem ticket can be published to a platform, the problem ticket can be fit into one or more categories/tags that exist on the platform. The categories/tags that are associated with a problem ticket can initially be submitted by the user who generated the problem ticket (Column 4, lines 54-67). The platform upon which the problem ticket is published can be organized in accordance with different categories and/or different tags, which can correspond to different categories/tags that are assigned to the problem tickets (column 5, lines 1-18).
“in response to receiving the first set of user-provided information pertaining to the new development issue, determining, from an originating issue database, a first set of potentially duplicate originating issue entries, the originating issue database being a structured database with an internal structure including fields for storing originating issue entries, top level issue sub-entries, contribution sub entries and issue parameters, where each originating issue can be associated to one top level issue sub-entry and one or more contribution sub entries, each being associated to issue parameters defined by the user- provided information and where each originating issue entry corresponds to a previously identified development issue, and each potentially duplicate originating issue entry represent a potential duplicate of the new development issue defined by the first set of user- provided information;”
if a selection of a given one of the first set of potentially duplicate originating entries is received, storing, in the originating issue database, the temporary issue entry as a new contribution sub-entry of the given selected originating issue entry.”
Siconolfi et al. further teaches, a problem ticket can be published to a platform, the problem ticket can be fit into one or more categories/tags that exist on the platform. The categories/tags that are associated with a problem ticket can initially be submitted by the user who generated the problem ticket (Column 4, lines 54-67). The platform upon which the problem ticket is published can be organized in accordance with different categories and/or different tags, which can correspond to different categories/tags that are assigned to the problem tickets (column 5, lines 1-18). Keyword and tags are stored in conjunction with the problem ticket (column 7, lines 10-25). Imagery of the problem ticket can be compared to images that were previously published. The previous images are associated with categories/tags, and these categories/tags of the previous image can also be assigned to the current problem ticket (column 5, lines 44-61). Information of the current problem ticket is determined to be similar to information of another problem ticket that was previously solved (column 6, lines 32-37). Also see column 7, lines 22-26.
However Siconolfi et al. does not explicitly appear to teach, “determining, from an originating issue database, a first set of potentially duplicate originating issue entries, the originating issue database being a structured database with an internal structure including fields for storing originating issue entries, top level issue sub-entries, contribution sub entries and issue parameters, where each originating issue can be associated to one top level issue sub-entry and one or more contribution sub entries, each being associated to issue parameters defined by the user- provided information and where each originating issue entry corresponds to a previously identified development issue, and each potentially duplicate originating issue entry represent a potential duplicate of the new development issue defined by the first set of user- provided information;”
if a selection of a given one of the first set of potentially duplicate originating entries is received, storing, in the originating issue database, the temporary issue entry as a new contribution sub-entry of the given selected originating issue entry.”
Burton et al. teaches, Software issue reports are submitted to the project management computer system, which in some cases, may house the issue repository (0033). Software issue reports are submitted indicating problems with software or requested features. Each resulting software issue report may include a description of the issue, for instance in prose, entered by a user or developer describing the problem (0020). Software issue reports include structured data. Values may include severity of an issue, whether the issue is a request for a new feature or a request to fix a problem, values indicating the type of the problem… etc (0021). Software issue graph stores records indicating relationships between software issue reports. Each software-issue report corresponds to a node in the graph and a relationship therebetween may correspond to an edge in the graph. The software-issue graph may take the form of a graph database storing a set of records each identifying a first node, a relationship, and a second node connected to the first node by the relationship (0035). The relationship in the software-issue graph are directed relationship, indicating a direction in which the relationship operates. Examples include one node being a genus to another node that is a species of that genus. In some cases, these may be referred to a parent-child relationship (0036). Edges may be weighted, with a value indicating the strength of a relationship. Edge weight may indicate that one software-issue report is a duplicate of another software issue report (0037). Also see 0040 and 0047. Burton et al. teaches if a third software issue report is a duplicate of a fourth software issue report, adding an edge to the software-issue graph indicating the third software-issue report is a duplicate of the fourth software-issue report (0006).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Siconolfi et al. with Burton et al. because both teach the creation and saving of an issue report/problem ticket. Siconolfi et al. teaches, the publishing of a problem ticket that can be organized in accordance with different categories and/or different tags, which can correspond to different categories/tags that are assigned to the problem tickets. Siconolfi et al. further teaches comparing problem tickets to images that were previously published to determine if they are similar. Burton et al. teaches storing issue reports in a graph/database that has relationships between nodes such as parent child relationships. If a report is a duplicate of another report the report is added the edge of the previous report. This will allow Siconolfi et al. to receive and save problem tickets along with their relationships to each other. The system will now know which reports are duplicates and are related to other reports and therefore would have been obvious to try.
As per claim 2, Siconolfi et al. and Burton et al. further teach, “The method of claim 1, further comprising:
receiving, from the first user, a supplementary set of user-provided information pertaining to the new development issue;
storing the supplementary set of user-provided information within the temporary issue entry;”
Siconolfi et al. teaches users are enabled to provide additional/supplemental information that is to be included with a problem ticket (column 4, lines 8-12).
“in response to receiving the supplementary set of user-provided information pertaining to the new development issue, determining, from the originating issue database, an updated set of potentially duplicate originating issue entries, each potentially duplicate originating issue entry of the updated set representing a potential duplicate of the new development issue defined by a combination of the first set of user-provided information and the supplementary set of user-provided information.”
Siconolfi et al. teaches, the platform upon which the problem ticket is published can be organized in accordance with different categories and/or different tags, which can correspond to different categories/tags that are assigned to the problem tickets (column 5, lines 1-18). Information of the current problem ticket is determined to be similar to information of another problem ticket that was previously solved (column 6, lines 32-37). Also see column 7, lines 22-26.
Burton et al. teaches, Software issue reports are submitted to the project management computer system, which in some cases, may house the issue repository (0033). Software issue reports are submitted indicating problems with software or requested features. Each resulting software issue report may include a description of the issue, for instance in prose, entered by a user or developer describing the problem (0020). Software issue reports include structured data. Values may include severity of an issue, whether the issue is a request for a new feature or a request to fix a problem, values indicating the type of the problem… etc (0021). Software issue graph stores records indicating relationships between software issue reports. Each software-issue report corresponds to a node in the graph and a relationship therebetween may correspond to an edge in the graph. The software-issue graph may take the form of a graph database storing a set of records each identifying a first node, a relationship, and a second node connected to the first node by the relationship (0035). The relationship in the software-issue graph are directed relationship, indicating a direction in which the relationship operates. Examples include one node being a genus to another node that is a species of that genus. In some cases, these may be referred to a parent-child relationship (0036). Edges may be weighted, with a value indicating the strength of a relationship. Edge weight may indicate that one software-issue report is a duplicate of another software issue report (0037). Also see 0040 and 0047. Burton et al. teaches if a third software issue report is a duplicate of a fourth software issue report, adding an edge to the software-issue graph indicating the third software-issue report is a duplicate of the fourth software-issue report (0006). Also see 0041-0043.
As per claim 3, Burton et al. further teaches, “The method of claim 2, further comprising:
if a selection of a given one of the new set of potentially duplicate originating entries is received, storing, in the originating issue database, the temporary issue entry as a new contribution sub-entry of the given selected originating issue entry of the new set of potentially duplicate originating entries.”
Burton et al. teaches if a third software issue report is a duplicate of a fourth software issue report, adding an edge to the software-issue graph indicating the third software-issue report is a duplicate of the fourth software-issue report (0006).
As per claim 4, Burton et al. further teaches, “The method of any one of claim 1, further comprising:
determining, for the selected given one of the potentially duplicate originating issue entries, an issue metric based on the issue parameters entries defined by the user-provided information stored in the new contribution sub-entry of the originating issue database and on one or more of issue parameters entries defined by the user-provided information associated to other contribution sub-entries of the originating issue database and to the top level issue sub-entry of the originating issue database, for the corresponding originating issue entry.”
Burton et al. teaches, software issue reports include structured data. Values may include severity of an issue, whether the issue is a request for a new feature or a request to fix a problem, values indicating the type of the problem… etc (0021). Software issue graph stores records indicating relationships between software issue reports. Each software-issue report corresponds to a node in the graph and a relationship therebetween may correspond to an edge in the graph. The software-issue graph may take the form of a graph database storing a set of records each identifying a first node, a relationship, and a second node connected to the first node by the relationship (0035). Edges may be weighted, with a value indicating the strength of a relationship. Edge weight may indicate that one software-issue report is a duplicate of another software issue report (0037). Also see 0040-0043 and 0047.
As per claim 5, Burton et al. further teaches, “The method of any one of claim 1, further comprising:
if a complete set of user-provided information pertaining to the new development issue is received without receiving a selection of one of the potentially duplicate originating issue entries, storing, in the originating issue database, the temporary issue entry as a top-level issue entry of a new originating issue entry with the new originating issue entry being unassociated with any other originating issue entries of the originating issue database.”
Burton et al. teaches Burton et al. teaches, software issue reports include structured data. Values may include severity of an issue, whether the issue is a request for a new feature or a request to fix a problem, values indicating the type of the problem… etc (0021). Software issue graph stores records indicating relationships between software issue reports. Each software-issue report corresponds to a node in the graph and a relationship therebetween may correspond to an edge in the graph. The software-issue graph may take the form of a graph database storing a set of records each identifying a first node, a relationship, and a second node connected to the first node by the relationship (0035). If a third software issue report is a duplicate of a fourth software issue report, adding an edge to the software-issue graph indicating the third software-issue report is a duplicate of the fourth software-issue report (0006). The examiner states that it would be inherent if there are no relationships or duplicates for a issue report it will be first node (top-level issue entry) in a new graph.
As per claim 7, Siconolfi et al. and Burton et al. further teach, “The method of any one of claims claim 1, further comprising:
receiving, from a second user, a for-contribution selection of a given one of the originating issue entries stored in the originating issue database and a request to make a contribution to the for-contribution selected originating issue entry;
in response to the request to make the contribution, creating a contribution sub-entry within the for-contribution selected given one of the originating issue entry in the originating issue database;
receiving and storing a set of for-contribution user-provided information pertaining to the contribution as issue parameter entries, within the newly created contribution sub-entry.”
Siconolfi et al. teaches users are enabled to provide additional/supplemental information that is to be included with a problem ticket (column 4, lines 8-12).Siconolfi et al. teaches, the platform upon which the problem ticket is published can be organized in accordance with different categories and/or different tags, which can correspond to different categories/tags that are assigned to the problem tickets (column 5, lines 1-18). Information of the current problem ticket is determined to be similar to information of another problem ticket that was previously solved (column 6, lines 32-37). Also see column 7, lines 22-26 and column 6, lines 24-37.
Burton et al. teaches, Software issue reports are submitted to the project management computer system, which in some cases, may house the issue repository (0033). Software issue reports are submitted indicating problems with software or requested features. Each resulting software issue report may include a description of the issue, for instance in prose, entered by a user or developer describing the problem (0020). Software issue reports include structured data. Values may include severity of an issue, whether the issue is a request for a new feature or a request to fix a problem, values indicating the type of the problem… etc (0021). Software issue graph stores records indicating relationships between software issue reports. Each software-issue report corresponds to a node in the graph and a relationship therebetween may correspond to an edge in the graph. The software-issue graph may take the form of a graph database storing a set of records each identifying a first node, a relationship, and a second node connected to the first node by the relationship (0035). The relationship in the software-issue graph are directed relationship, indicating a direction in which the relationship operates. Examples include one node being a genus to another node that is a species of that genus. In some cases, these may be referred to a parent-child relationship (0036). Edges may be weighted, with a value indicating the strength of a relationship. Edge weight may indicate that one software-issue report is a duplicate of another software issue report (0037). Also see 0040 and 0047. Burton et al. teaches if a third software issue report is a duplicate of a fourth software issue report, adding an edge to the software-issue graph indicating the third software-issue report is a duplicate of the fourth software-issue report (0006). Also see 0041-0043.
As per claim 8, Burton et al. further teaches, “The method of claim 7, further comprising determining, for the for- contribution selected given one of the originating issue entry, an issue metric based on the issue parameters entries defined by the user-provided information stored in the new contribution sub-entry of the originating issue database, and on one or more of issue parameters entries defined by the user-provided information associated to other contribution sub-entries of the originating issue database and to the top level issue sub- entry of the originating issue database, for the corresponding originating issue entry.”
Burton et al. teaches, software issue reports include structured data. Values may include severity of an issue, whether the issue is a request for a new feature or a request to fix a problem, values indicating the type of the problem… etc (0021). Software issue graph stores records indicating relationships between software issue reports. Each software-issue report corresponds to a node in the graph and a relationship therebetween may correspond to an edge in the graph. The software-issue graph may take the form of a graph database storing a set of records each identifying a first node, a relationship, and a second node connected to the first node by the relationship (0035). Edges may be weighted, with a value indicating the strength of a relationship. Edge weight may indicate that one software-issue report is a duplicate of another software issue report (0037). Also see 0040-0043 and 0047.
As per claim 9 (Currently Amended), Siconolfi et al. further teaches, “The method of claim7, wherein the set of for- contribution user-provided information pertaining to the contribution for the given one of the originating issue entries includes one of a validation of the given one of the originating issue entries or an invalidation of the given one of the originating issue entries.”
Siconolfi et al. teaches information relating to the problem ticket can also be compared again historical data to determine if any other user has previously resolved (verified) a problem similar to the problem described by the problem ticket (column 7, lines 22-26).
Claims 11-20 and 22-24, claim similar limitations to claims 1-5 and 7-9 and are therefore rejected for the same reasons.
Response to Arguments
Applicant's arguments filed 10/16/2025 have been fully considered but they are not persuasive.
Regarding 35 U.S.C. §101 Rejection
Applicant argues:
“As highlighted above, in addition to the "creating" and "determining" limitations generally cited by the Examiner, claim 1 is also directed to a structured database in which a "new development issue" is appropriately searched and associated with "one top level issue sub-entry" or "one or more contribution sub entries" based on whether the new development issue is a "potentially duplicate originating issue." This represents a fundamentally novel method for determining the duplicity of a new entry to the structured database at the input stage, with the "temporary issue entry" then appropriately stored in the structured database.
The present claims are directly analogous to the claims in Enfish v. Microsoft, 822 F.3d 1327 (Fed. Cir. 2016). In Enfish, the Federal Circuit held claims eligible where they improved the way computers operate, even if they involved data structures. In Enfish, the Federal Circuit analyzed whether the claims were directed to the abstract idea of "storing, organizing, and retrieving memory in a logical table" or, more simply, "the concept of organizing information using tabular formats." Id. at 1337. The Federal Circuit cautioned that describing the claims at such a high level of abstraction and untethered from the language of the claims all but ensures that the exceptions to § 101 swallow the rule. Id.; see also Diamond v. Diehr, 450 U.S. 175, 189 n. 12, 101 S.Ct. 1048 (1981) (cautioning that overgeneralizing claims, "if carried to its extreme, make[s] all inventions unpatentable because all inventions can be reduced to underlying principles of nature which, once known, make their implementation obvious"). As in Enfish, because the pending claims are not directed to an abstract idea under step one of the Alice analysis, it is unnecessary to proceed to step two of that analysis.”
Applicant states the currently claimed limitations are analogous to the claims in Enfish v. Microsoft, 822 F.3d 1327 (Fed. Cir. 2016)). The examiner disagrees. The examiner states that in Enfish v. Microsoft, the Federal Circuit reversed the district court's summary judgment ruling that all claims were patent–ineligible abstract ideas under Alice. Instead, the claims were directed to a specific improvement to the way computers operate, embodied in the claimed "self-referential table" for a database, which the relevant prior art did not contain. Enfish claims:
“A data storage and retrieval system for a computer memory, comprising:
means for configuring said memory according to a logical table, said logical table including:
a plurality of logical rows, each said logical row including an object identification number (OID) to identify each said logical row, each said logical row corresponding to a record of information;
a plurality of logical columns intersecting said plurality of logical rows to define a plurality of logical cells, each said logical column including an OID to identify each said logical column; and
means for indexing data stored in said table.”
Enfish is claiming a specific configuration of an improved database structure that allows faster lookups and more efficient storage of data. However, the examiner does not believe this is analogous to the current claimed invention. The limitations to claim 1 do nothing more than receive a new development issue, create a temporary issue entry, determining from an originating issue database a first set of potentially duplicate originating issue entries, if one of the duplicate originating entries is selected, the temporary stored issue is stored as a new contributing sub-entry of the given selected originating issue entry. As claimed a set of potentially duplicate originating issues are determined from an originating issue data base. The claim states that the originating issue database is a structured database with an internal structure including fields for storing originating issue entries, top level issue sub-entries, contribution sub entries and issue parameters. The claim then states that these fields are related to the originating issue entries and that each potential duplicate originating issue entry represents a potential duplicate of the new development issue. However, nowhere in said claimed limitation is it stated how this databased is searched and used based on its fields. As claimed in a broadest reasonable interpretation, the claimed database is nothing more than a database with a plurality of fields that are compared to a prospective new entry to see if it already exists. The database does not improve the way the computer system operates since there is no specific mention on how it is used for the determination (comparison) step. Enfish is geared towards a specific structure of a database that allows indexing which is not analogous to the current claimed invention.
Applicant further argues,
“Even if the present claims were found to be directed to an abstract idea under Step 2A, Prong One, under Step 2B, they include additional elements that amount to significantly more than the alleged abstract idea. Specifically, the claims recite a particular structured database that improves processing efficiency for tracking of issues in the ongoing development process of a software application answers to a computer problem by structuring the data related to identified issues and preventing or at least minimizing duplicate issue entries being stored in the corresponding database, thereby efficiently managing data storage size. The improved system and method for tracking of issues in the ongoing development process of a software application also allows automated prioritization of the reported issue. See, e.g., Appl. at 13.
This represents a technical improvement over conventional systems, not found in the prior art, as discussed below with respect to the cited prior art. As such, claim l's limitations, considered12
individually and in ordered combination, reflect a non-conventional and non-generic arrangement that provides practical application and satisfies the requirements of Step 2B.”
Applicant argues that the additional elements amount to significantly more than the alleged abstract idea and that the particular structured database improves processing efficiency for tracking of issues the ongoing development process of a software application answers to a computer problem by structuring the data related to identified issues and preventing or at least minimizing duplicate issue entries being stored in the corresponding database, thereby efficiently managing data storage size. The examiner respectfully disagrees. As stated above the structure of the database is claimed, however nothing in the claimed invention states how the structure is being used to determine possible duplicate entries. As claimed, the determination step could be nothing more than a basic comparison of data fields. Further as claimed there is no improvement to data storage size or minimizing of duplicate issues. As claimed, the temporary issue is saved to the originating issue database. There is nothing in the claim preventing a temporary issue from being saved while others are being saved. Therefore, the additional elements do not amount to significantly more.
Lastly the applicant argues:
“Additionally, the Examiner generalizes the activities of "receiving" and "storing" as "well- understood, routine, conventional activities" while failing to address the limitations of claims 1 and 11 related to the benefits of the structured database. As expressly stated in the USPTO's Berkheimer Memo, the Examiner cannot rely on such boilerplate language and must support any such conclusions with factual evidence, including a citation to a publication (e.g., textbooks, prior art), a statement of common knowledge supported by a reference, or an admission by the Applicant. The Examiner has failed to provide any factual support for his boilerplate conclusions, which should therefore be deemed withdrawn.”
Regarding the applications arguments to the activities of “receiving” and “storing” as well-understood, routine, conventional activities the examiner disagrees. The examiner points to “MPEP2106.05(d) II ELEMENTS THAT THE COURTS HAVE RECOGNIZED AS WELL-UNDERSTOOD, ROUTINE, CONVENTIONAL ACTIVITY IN PARTICULAR FIELDS”. This section states “i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added));. The sections further states, “iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;”. Therefore, “receiving” and “storing” are well understood, routine and conventional activities.
For the reasons stated above the current 35 U.S.C. §101 Rejections stands.
Regarding Rejection Under 35 U.S.C § 103
Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant argues:
“As admitted by the Examiner, Siconolfi does not teach a structured database in which a "new development issue" is appropriately searched and associated with "one top level issue sub- entry" or "one or more contribution sub entries" based on whether the new development issue is determined to be a "potentially duplicate originating issue," as is required by independent claims 1 and 11. This represents a fundamentally novel method for determining the duplicity of a new entry to the structured database at the input stage, with the "temporary issue entry" then appropriately stored in the structured database.”
The examiner disagrees. First the examiner would like to state the claimed limitations do not explicitly teach “a structured database in which a “new development issue” is appropriately search and associated with “one top level sub-entry” or “one or more contributions entries” based on whether the new development issue is determine to be a “potentially duplicate originating issue”. As claimed “determining from an originating issue database, a first set of potentially duplicate originating issue entries… each potentially duplicate originating issue entry represents a potential duplicate of the new development issue defined by the first set of user provided information”. This limitation is stating a set of potentially duplicate originating issue entries are determined from a structured database based on a first set of user-provided information. The claim also states “the originating issues can be associated with to one top level issue sub-entry and one or more contribution sub entries, each being associated to issue parameters defined by the user-provided information”. However, the claim does not go into specific steps on how the structure of the database is used.
Siconolfi et al. teachs a platform in which a problem ticket is published that is organized according with different categories and/or different tags, which can correspond to different categories/tags that are associate to the problem ticket (column 5, lines 1-18). The examiner states that a platform organized as taught by Siconolfi et al. is a structured database. Further, Siconolfi et al. teaches Imagery of the problem ticket can be compared to images that were previously published that are associated with categories/tags that can also be assigned to the problem ticket (column 5, lines 44-61). Information of the current problem ticket is determined to be similar to information of another problem ticket that was previously solved (column 6, lines 32-37). Therefore, the organized platform (database) of Siconolfi is searched for a similar problem ticket that are organized in accordance with different categories and/or tags.
Applicant further argues:
“Burton does not cure this shortcoming in the teachings of Siconolfi. Burton is directed to a computer system designed to generate a "software issue graph" using a machine language model trained based on user adjustments to previous outputs of the model indicating incorrect edges. For example, claim 15 describes "the software issue graph is formed with a machine-learning model obtained trained by obtaining a log of historical workflow instances addressing software-issue reports and training the machine learning model used to form the software-issue graph with the log of historical workflow instances, and the machine-learning model is updated based on user adjustments to previous outputs of the model indicating incorrect edges."
Similar to Burton, the present application also teaches the use of machine learning to determine duplicate issues, as described in 94
[94] In an embodiment, the identification of the potentially duplicate originating issue entries 64 can be carried out using a machine learning model configured to define a similarity score for each one of the originating issue entries 64 of the originating issue database 56. For example and without being limitative, the machine learning model can be trained using training datasets including labelled data including issue parameters 80 of originating issue entries 64. The machine learning model can be retrained over time using additional available data, thereby improving the search accuracy over time.
As is evident, independent claims 1 and 11 relate to the addition to the structured database itself. The determination of duplicity in the structured database is determined at the input stage a request for submitting an issue is first, then a temporary issue entry is created, then the user- provided information is received, then that information is stored within the temporary entry, then the system determines duplicity and stores the temporary issue entry accordingly in a structured database (and stored with an associated "issue metric", see claim 4).
Burton is fundamentally different-issue reports are automatically stored in the database. A developer then generates a software issue graph 55 from ML model 38, creating vectors for determining duplicity in the stored issue reports. The presently pending claims are significantly directed to the structured database and the method of inputting issue reports and determining duplicity at intake. Burton is not. As such, the combination of Siconolfi and Burton fails to teach each and every limitation of independent claims 1 and 11. Applicant respectfully requests withdrawal of the obviousness rejection.””
The examiner disagrees. Burton et al. teaches that issue reports include structured data (0021) and that a software issue graph stores records indicating relationships between software reports. The software issue graph may take the form of a graph database storing a set of records each identifying a first node, a relationship, and a second node connected to the first node by relationship (0035). Therefore, Burton et al. is teaching the structed database for storing information regarding a software issue. For these reasons the current rejections stand. The examiner further states that applicant argues that Siconolfi et al. and Burton, not in combination as used in the rejection. Siconolfi et al. teaches if a user encounters a problem, the user can report the problem by generating an indication of the problem. The user can generate a problem ticket, where the problem ticket describes the presence of the problem and describes characteristics of the problem (column 3, lines 35-41). Also see column 4, lines 38-53). Upon generating the problem ticket, the use can submit information to fill some required fields of the problem ticket (column 6, lines 57-65). The problem ticket can be published to allow collaboration (column 3, lines 20-35). Burton et al. teaches a plurality of fields including a relationship between reports . The examiner states that it is inherent that the problem ticket is stored in some type of memory and that the problem ticket is temporary until it is published for collaboration.
Conclusion
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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6:00pm.
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, Lewis Bullock can be reached at 571-272-3759. 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.
/MARK A GOORAY/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199