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 .
DETAILED ACTION
This office action is in response to communication filed 1/30/2026. Claims 1-7, 9-16, and 18-19 are currently pending and claims 8 and 17 are cancelled. Claims 1, 10, and 19 are the independent claims.
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-7, 9-16, and 18-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As per independent claim 1, it recites “A computer-implemented method of producing high-level report data from low-level data extracted from a repository of one or more software objects in a software version control system which tracks changes to the one or more software objects over time, the method comprising, by at least one computer system, the operations of: receiving sets of commit source data extracted from the repository of the one or more software objects in the software version control system, each set of commit source data including commit patches which describe how to modify the one or more software objects to arrive at a new state of the one or more software objects; processing the commit patches to obtain hunk records and a list of any renamed, deleted or created software objects, the hunk records comprising records for individual segments of changed content in each commit patch; processing the hunk records utilizing a commit-blame procedure to produce output records indicating history and original source of changes from the commit patches; performing the commit-blame procedure on input commits and commit patches to produce intermediate data records for at least one of the input commits and software; analyzing the intermediate data records to obtain information relating to whether executable software code is still surviving in a software code base or when the executable software code was removed from the software code base; determining how long the executable software code survived in the software code base, wherein the operation of determining includes the operation of analyzing a plurality of future change sets or commits to identify a change set or commit that removed or modified the executable software code; and producing at least one report by aggregating the information.” The limitations “processing the commit patches to obtain hunk records and a list of any renamed, deleted or created software objects, the hunk records comprising records for individual segments of changed content in each commit patch”, “processing the hunk records utilizing a commit-blame procedure to produce output records indicating history and original source of changes from the commit patches”, “performing the commit-blame procedure on input commits and commit patches to produce intermediate data records for at least one of the input commits and software”, “analyzing the intermediate data records to obtain information relating to whether executable software code is still surviving in a software code base or when the executable software code was removed from the software code base”, and “determining how long the executable software code survived in the software code base, wherein the operation of determining includes the operation of analyzing a plurality of future change sets or commits to identify a change set or commit that removed or modified the executable software code” as drafted, recites a function that, under its broadest reasonable interpretation, covers a function that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. For example, a human may mentally/with pen and paper/etc. process/analyze/judge/etc. commit patches and determine/identify/locate/etc. record/changed content/etc., process/analyze/judge/etc. hunk records/records/data/etc. and determine/identify/decide/etc. history and origin of changes, judge/evaluate/analyze/etc. input commits/data/etc. and determine/identify/decide/etc. data/intermediate data/etc. for input commits/data and software, judge/analyze/evaluate/etc. data/intermediate data records and decide/identify/determine/etc. whether code is still in code base or has been removed, and may judge/determine/observe/etc. how long code/software has survived in the code base by evaluating/analyzing/judging/observing/etc. change sets/future commits/etc. and determining/identifying/observing/judging/etc. change set/commit that removed or modified the code. As such, with broadest reasonable interpretation, the limitations cover a human mind carrying out the function through observation, evaluation, judgment, and/or opinion, or even with the aid of pen and paper. Thus, the limitations recite and falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. The claim recites the additional elements “A computer-implemented method of producing high-level report data from low-level data extracted from a repository of one or more software objects in a software version control system which tracks changes to the one or more software objects over time, the method comprising, by at least one computer system, the operations of”, “receiving sets of commit source data extracted from the repository of the one or more software objects in the software version control system, each set of commit source data including commit patches which describe how to modify the one or more software objects to arrive at a new state of the one or more software objects” and “producing at least one report by aggregating the information.” The additional element “A computer-implemented method of producing high-level report data from low-level data extracted from a repository of one or more software objects in a software version control system which tracks changes to the one or more software objects over time, the method comprising, by at least one computer system, the operations of” recites that high level/generic computer components/at least one computer system, repository, version control system, etc./etc. are used to perform/implement the abstract idea/mental process, and as such amount to mere instructions to apply the exception using generic computer components. The additional element “receiving sets of commit source data extracted from the repository of the one or more software objects in the software version control system, each set of commit source data including commit patches which describe how to modify the one or more software objects to arrive at a new state of the one or more software objects” recites an insignificant extra solution activity of gathering/obtaining/receiving/etc. data/information/commit source data/etc. and the courts have identified mere data gathering is well-understood, routine and conventional activity (see MPEP 2106.05(d)). The additional element “producing at least one report by aggregating the information” recites outputting a result of the abstract idea/mental process and is at best the equivalent of merely adding the words “apply it” to the judicial exception. 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. See MPEP 2016.05(f), 2106.05(g).
The claim does 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 amount to mere instructions to apply the abstract idea using generic computer components, a mere extra solution activity of gathering/obtaining/receiving data/information and the courts have identified mere data gathering and transmitting are well-understood, routine, and conventional activity, see MPEP 2106.05(d), and outputting a result which is at best the equivalent of merely adding the words “apply it” to the abstract idea/judicial exception/mental process, and mere instructions to apply an exception does not provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
As per claim 2, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein each set of commit source data includes a list of commits and a list of refs which are names or tokens associated with particular commit identifiers” which, conceptually, with broadest reasonable interpretation, provides further clarification as to data/information/etc. gathered/received/obtained/etc. and used to perform the abstract idea/mental process/etc. and the courts have identified mere data gathering is well-understood, routine and conventional activity (see MPEP 2106.05(d)), and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 2 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 3, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein each set of commit source data is extracted through an application programming interface (API) of the software version control system” which, conceptually, with broadest reasonable interpretation, provides further clarification as to data/information/etc. gathered/received/obtained/etc. and used to perform the abstract idea/mental process/etc. and the high level/generic computer components used to implement/perform the abstract idea/mental process, and the courts have identified mere data gathering is well-understood, routine and conventional activity (see MPEP 2106.05(d)), and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 3 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 4, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the output records include at least one of hunk fragment records, hunk removal records, hunk context records and blame records” which conceptually, with broadest reasonable interpretation, provides further clarification as to the performance of the abstract idea/mental process, and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 4 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 5, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the step of performing includes planning an execution order of the commit-blame procedure on each set of commit source data that was extracted and needs processing” which conceptually, with broadest reasonable interpretation, provides further clarification as to the performance of the abstract idea/mental process, and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 5 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 6, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the step of producing includes identifying attributes associated with the executable software code” which conceptually, with broadest reasonable interpretation, provides further clarification as to the performance of the abstract idea/mental process, and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 6 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 7, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…further comprising generating a grouping of the intermediate data records into groups based on the attributes and computing aggregate values for each group to produce the high-level report data which can be used to generate reports which can be presented to a user of the reports” which conceptually, with broadest reasonable interpretation, provides further clarification as to the performance of the abstract idea/mental process, and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 7 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 9, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…further comprising determining amount of time it took to write the survived software code” which conceptually, with broadest reasonable interpretation, provides further clarification as to the performance of the abstract idea/mental process, and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 9 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per independent claim 10, it recites a system having similar limitations to the method of claim 1, and is therefore rejected for similar reasoning as claim 1, above, and claim 10 further recites “the system computing comprising: at least one hardware processor; and at least one storage device coupled to the at least one hardware processor for storing instructions that are operable when executed by the at least one hardware processor to cause the at least one hardware processor to perform operations comprising” which provides further clarification as to high level/generic computer components used to implement/perform the abstract idea/mental process/judicial exception, which amounts to no more than mere instructions to apply the exception using generic computer components which does not provide an inventive concept. Accordingly, these additional limitations/elements are not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, the additional limitations/elements of claim 10 fail to correct the deficiencies of claim 1, and therefore claim 10 is rejected for similar reasoning as claim 1, above.
As per claims 11-16 and 18, they recite systems having similar reasoning as the methods of claims 2-7 and 9, respectively, and are therefore rejected for similar reasoning as claims 2-7 and 9, respectively, above.
As per independent claim 19, it recites a computer readable storage medium having similar limitations as the method of claim 1, and is therefore rejected for similar reasoning as claim 1, above. Claim 19 further recites the additional elements “a non-transitory computer readable storage medium storing a program of instructions executable by a machine to perform operations, the operations comprising” which, with broadest reasonable interpretation, provides further clarification as to the high level/generic computer components used to implement/perform the abstract idea/mental process, which amounts to no more than mere instructions to apply the exception using generic computer components which does not provide an inventive concept. Accordingly, these additional limitations/elements are not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, the additional limitations/elements of claim 19 fail to correct the deficiencies of claim 1, and therefore claim 19 is rejected for similar reasoning as claim 1, above.
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-7, 10-16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Turner et al. (herein called Turner) (US Patent 10,289,407 B1) in further view of Gattu et al. (herein called Gattu) (US Patent 10,503,713 B1).
As per claim 1, Turner teaches: a computer-implemented method of producing high-level report data from low-level data extracted from a repository of one or more software objects in a software version control system which tracks changes to the one or more software objects over time, the method comprising, by at least one computer system, the operations of:
receiving sets of commit source data extracted from the repository of the one or more software objects in the software version control system, each set of commit source data including commit patches which describe how to modify the one or more software objects to arrive at a new state of the one or more software objects (col. 6 lines 9-20, col. 13 lines 8-10, 45-55, col. 14 lines 25-58, commit data from source code retrieved/accessed/extracted/etc. from database and repository is received (receive sets of commit source data extracted from the repository of the one or more software objects in the software version control system), and metadata/comment/etc. (commit patches) of commit/commit data/commit patches describe the changes/modifications/etc. made to the source code (each set of commit source data including commit patches which describe how to modify the one or more software objects to arrive at a new state of the one or more software objects).);
processing the commit patches to obtain hunk records and a list of any renamed, deleted or created software objects, the hunk records comprising records for individual segments of changed content in each commit patch (col. 6 lines 15-20, col. 13 lines 58-65, col. 14 lines 59-67, col. 16 lines 13-64, commit data/metadata/comments/etc. is processed and portion/lines/hunks of code are determined/identified that have been added/removed/modified/etc. (to obtain hunk records for individual segments/lines/portions of code that have been added/removed/modified/changed content in each commit patch/commit data/metadata/etc.).) ;
processing the hunk records utilizing a commit-blame procedure to produce output records indicating history and original source of changes from the commit patches (co. 16 lines 13-65, col. 20 lines 4-10, hunks/hunk records/etc. are processed using a procedure to determine differences between versions/previous version and latest version/etc. and determine whether lines/code changes come from source side/previous version or target site/latest version/etc. (indicating history and original source of changes from the commit patches) of code and output hunks that have been prepared before and after the changing, addition or removal or content (produce output records indicating history and original source of changes from the commit patches).);
performing the commit-blame procedure on input commits and commit patches to produce intermediate data records for at least one of the input commits and software (col. 16 lines 13-28, prepared hunks making state of the code available (intermediate data records) are created for versions of source code having changed lines of code/commits having comments/etc. (for input commits/software) by processing code versions/commits/input commits/commit patches/etc. having changed lines of code (performing commit-blame procedure on input commits and commit patches).);
analyzing the intermediate data records to obtain information relating to whether executable software code is still surviving in a software code base or when the executable software code was removed from the software code base (col, 16 lines 13-64, prepared hunks (intermediate data records) are processed/analyzed/etc. to determine whether commented code has been removed/added/still exists/etc. (information relating to whether executable software code is still surviving in or was removed from software code base).); and
producing at least one report by aggregating the information (col. 22 lines 51-67, system reports/produces report/etc. if any changes have occurred from aggregating the hunks/by aggregating the information.).
Turner does not explicitly state, however Gattu teaches:
determining how long the executable software code survived in the software code base, wherein the operation of determining includes the operation of analyzing a plurality of future change sets or commits to identify a change set or commit that removed or modified the executable software code (col. 2 line 40-col. 3 line 2, col. 4 line 58-col. 5 line 15, col. 7 lines 33-41, col. 7 line 63-col 8 line 4, col. 8 lines 54-col.9 line 8, policy for data object (executable software code) retention may specify timespan that object/code is retained in storage before being deleted after being designated as non-current version after succeeding/subsequent version of object is created and designated as current version, and non-current timespan of object designated as non-current is calculated by measuring the difference between a present time and timestamp of creation of object succeeding the non-current object, and there may be multiple subsequent versions of an object that are evaluated to determine the version that succeeded/replaced a non-current object/executable code (determine how long/timespan/etc. object/executable software code has survived/been retained/etc. in storage/codebase by analyzing multiple future/succeeding/subsequent/etc. change sets or commits/version of object/etc. to identify a change set or commit/succeeding object version/etc. that removed or modified the executable software code/was designated as current object over previous version of object/etc.).).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add determining how long the executable software code survived in the software code base, wherein the operation of determining includes the operation of analyzing a plurality of future change sets or commits to identify a change set or commit that removed or modified the executable software code, as conceptually taught by Gattu, into that of Turner because these modifications allow for older/longer surviving/longer retained/etc. non-current versions that may not be used to be identified so they may be deleted, thereby saving resources/memory/etc. that would be spent storing versions that are no longer used/no longer up to date/etc..
As per claim 2, Turner further teaches: wherein each set of commit source data includes a list of commits and a list of refs which are names or tokens associated with particular commit identifiers (Co. 28 lines 15-51, commit data/commit source data/etc. includes/stores/etc. list of files/names of files/labeled lines of code/etc. in commit/list of commits/list of refs which are names associated with commit identifier.).
As per claim 3, Turner further teaches: wherein each set of commit source data is extracted through an application programming interface (API) of the software version control system (col. 2 lines 4-7, col. 5 line 60-col. 6 line 10, col. 13 lines 8-10, repository management system server/software version control system comprises an API used to perform functions including the extraction/retrieving/etc. of records/version of source code/each set of commit source data.).
As per claim 4, Turner further teaches: wherein the output records include at least one of hunk fragment records, hunk removal records, hunk context records and blame records (col. 16 lines 13-67, hunks/hunk records are processed using a procedure and output hunk fragments/lines/files included in hunks/lines/files removed/etc. (output records include hunk fragment records/removal records).).
As per claim 5, Turner further teaches: wherein the step of performing includes planning an execution order of the commit-blame procedure on each set of commit source data that was extracted and needs processing (col. 16 lines 17-25, successive hunks/code portions/etc. of versions of source code/commits/etc. are processed successively until all comments/portions/etc. have been processed/resolved/etc. (planning an execution order/successive order/processed successively/etc. of the commit-blame procedure on each set of commit source data/hunks/portions of versions of source code/commits/etc. that was extracted and needs processing).).
As per claim 6, Turner further teaches: wherein the step of producing includes identifying attributes associated with the executable software code (col. 22 lines 51-67, values of source and destination branches/repositories are adjusted to match and compare commit/incoming/etc. source code with destination/existing source code, determine how destination repository/existing code/etc. has changed since user began working/commit/incoming code version was made/etc., changes/no changes in code are determined, etc. (identify attributes associated with executable software code).).
As per claim 7, Turner further teaches: generating a grouping of the intermediate data records into groups based on the attributes and computing aggregate values for each group to produce the high-level report data which can be used to generate reports which can be presented to a user of the reports (col. 22 lines 51-67, values of source and destination branches/repositories are adjusted to match and compare incoming commit/changes/source code/hunks/intermediate data records/etc. with destination code branch/existing source code/matching hunks/existing intermediate data records/etc. (group/match/intermediate data records based on attributes/matching code/etc.), determine how destination repository/existing code/etc. has changed since user began working/commit/incoming code version was made/etc., and changes/no changes in code are determined and reported to user along with suggestions for merging changes (aggregate values for each group to produce the high-level report data which can be used to generate reports which can be presented to a user of the reports).).
As per claims 10-16, they recite systems having similar limitations as the methods of claims 1-7, respectively, and are therefore rejected for similar reasoning as claims 1-7, respectively, above.
As per claim 19, it recites a computer readable storage medium having similar limitations as the method of claim 1, and is therefore rejected for similar reasoning as claim 1, above.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Turner et al. (herein called Turner) (US Patent 10,289,407 B1) and Gattu et al. (herein called Gattu) (US Patent 10,503,713 B1) in further view of Pidduck (US PG Pub. 2016/0259799 A1).
As per claim 9, Turner does not explicitly state, however Pidduck teaches:
determining amount of time it took to write the survived executable software code (fig. 3A pars. [0046], [0049], [0051], [0070], time/timeframe (amount of time) to create/generate/write versions/software code/time between new version being created/new version number stored and previous version being created/previous version number stored/etc. in version storage (survived/retained/stored/etc. executable software code) is determined/identified using timelines.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add determining amount of time it took to write the survived software code, as conceptually taught by Pidduck, into that of Turner and Gattu, because these modifications allow for information regarding how long/resources it takes/etc. to write/develop/etc. code to be determined included in the report about the code which is desirable as it provides additional information to be included in the report thereby allowing for more information to provided to users for making decisions, allowing for users to be better informed and increasing the usability and desirability of the reports.
As per claim 18, it recites a system having similar limitations as the method of claim 9, and is therefore rejected for similar reasoning as claim 9, above.
Response to Arguments
Applicant's arguments filed 1/30/2026 have been fully considered but they are not persuasive.
As per the 101 arguments on pg. 7 par. 2-pg. 8 par. 4 of the remarks that the amended independent claims are allowable under 35 USC 101 because they are not directed to an abstract idea/mental process as the amended independent claims provide a specific technical solution to a problem in the context of determining whether executable software code survives in a codebase, and the operations of the amended independent claims are executed by at least one computer system and includes structural and operational features that reflect technological considerations rather than abstract logic, and as such recite a specific technical method implemented in at least one computer system and therefore are not abstract and integrate any possible exception into a practical application and recites significantly more than any possible exception, and therefore the amended independent claims and their respective dependent claims are allowable, the examiner, respectfully, disagrees.
The examiner would like to point out that, with broadest reasonable interpretation, the amended independent claims recite limitations/elements/etc. that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components, as seen in the rejection of claim 1 under 35 USC 101 above, and as such the independent claims do recite an abstract idea/mental process. Additionally, the claims do not recite/clarify/etc. technical components/specific technical operations being performed using specific computer component that can not be performed by a human/how specific computer components are performing computer operations to performing the limitations/etc., but rather recite that the limitations are performed by high level/generic computer/components/computer system/etc., as seen in the rejection of claim 1 under 35 USC 101 above, and as such, with broadest reasonable interpretation, the claims are not tied to a specific technical solution/does not include structural and operational features that reflect specific technological considerations/etc.. Therefore the additional limitations/elements amount to mere instructions to apply the abstract idea using generic computer components, a mere extra solution activity of gathering/obtaining/receiving data/information and the courts have identified mere data gathering and transmitting are well-understood, routine, and conventional activity, see MPEP 2106.05(d), and outputting a result/aggregating information to produce a report/etc. which is at best the equivalent of merely adding the words “apply it” to the abstract idea/judicial exception/mental process, and mere instructions to apply an exception does not provide an inventive concept, as seen in the rejection of claim 1 under 35 USC 101 above. Accordingly, the claims are not patent eligible under 35 USC 101.
Therefore, the examiner finds these arguments unpersuasive and maintains that the rejection under 35 USC 101 is proper.
Applicant’s 102/103 arguments with respect to claim(s) 1-7, 9-16, and 18-19 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.
As per the 102/103 arguments on pg. 8 par. 5-pg. 9 par. 5 of the remarks that Turner et al. (herein called Turner) (US Patent 10,289,407 B1) and Pidduck (US PG Pub. 2016/0259799 A1) do not teach all amended features/limitations of the amended independent claims, and therefore the amended independent claims and their respective dependent claims are allowable, the examiner, respectfully, disagrees. The examiner would like to point out that the new reference Gattu et al. (herein called Gattu) (US Patent 10,503,713 B1) is currently relied upon to correct the deficiencies of Turner with respect to the amended independent claims, and therefore the arguments 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.
Therefore, the examiner finds these arguments unpersuasive and maintains that the rejection under 35 USC 103 is proper.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 DOUGLAS M SLACHTA whose telephone number is (571)270-0653. The examiner can normally be reached Monday-Friday 6:30am-4pm.
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, Chat Do can be reached at 571-272-3721. 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.
/DOUGLAS M SLACHTA/Examiner, Art Unit 2193