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 application is a 371 of PCT/NZ2023/050062 06/27/2023
This application also claims benefit of foreign applications AUSTRALIA 2022901903 filed on 07/07/2022 and AUSTRALIA 2022902574 filed on 09/07/2022.
Status of Claims
Claims 1-4, 6, 16, 22, 23, 26, 27, 29, and 32-49 are canceled.
Claims 5, 7-15, 17-21, 24, 25, 28, 30, and 31 are currently pending and rejected.
Claim Rejection – 35 U.S.C. 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 5, 7-15, 17-21, 24, 25, 28, 30, and 31 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The rationale for this finding is explained below. In the instant case, the claims are directed towards providing graphical user interfaces for presenting debt repayment information. The concept is clearly related to providing information to user to influence human financial behavior, thus the present claims fall within the Certain Method of Organizing Human Activity grouping. The claims do not include limitations that are “significantly more” than the abstract idea because the claims do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Note that the limitations, in the instant claims, are done by the generically recited computer device. The limitations are merely instructions to implement the abstract idea on a computer and require no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry. Therefore, claims 5, 7-15, 17-21, 24, 25, 28, 30, and 31 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Step 1: The claims 5, 7-15, 17-21, 24, 25, 28, and 30 are directed to a process, machine, manufacture, or composition matter. Claim 31 is not directed to any of the statutory subject matter.
In Alice Corp. Pty. Ltd. v. CLS Bank Intern., 134 S. Ct. 2347 (2014), the Supreme Court applied a two-step test for determining whether a claim recites patentable subject matter. First, we determine whether the claims at issue are directed to one or more patent-ineligible concepts, i.e., laws of nature, natural phenomenon, and abstract ideas. Id. at 2355 (citing Mayo Collaborative Servs. v. Prometheus Labs., Inc., 132 S. Ct. 1289, 1296–96 (2012)). If so, we then consider whether the elements of each claim, both individually and as an ordered combination, transform the nature of the claim into a patent-eligible application to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept itself.
Claims 5, 7-15, 17-21, 24, and 25 are directed to a process (i.e., method claims).
Claim 28 is directed to a machine (i.e., device/system claims).
Claim 30 is directed to a manufacture (i.e., machine-readable medium claims).
Claim 31 is directed to a graphical user interface, which is software per se and not a statutory subject matter.
Step 2A: The claims are directed to an abstract idea.
Prong One
The present claims are directed towards providing graphical user interfaces for presenting debt repayment information. The concept comprises presenting a user interface for a user account where the user interface displays an invoice or bill associated with a debt, presenting a selectable option to select a payment plan type, determining a user selected combination payment plan, presenting a payment progress indicator representative of at least two distinct payment schedules of the combination payment plan, modifying the payment progress indicator upon receiving a payment. The concept arranges payment information on a GUI in a manner that assists users in processing payment information more quickly. The concept is clearly related to providing information to user to influence human financial behavior, thus the present claims fall within the Certain Method of Organizing Human Activity grouping. The performance of the claim limitations using generic computer components (i.e., a display device of a first device and a processor) does not preclude the claim limitation from being in the certain methods of organizing human activity grouping. Accordingly, the present claims recite an abstract idea.
Prong Two
Independent claim 5 recites a display device and a processor as additional element. Dependent claims 7-15, 17-21, 24, 25 do not recite any other additional element. Independent claim 28 recites a memory, a processor, and a display device of a first device as additional elements. Independent claim 30 recites a non-transitory machine readable medium, a processor, and a display device of a first device as additional elements. Claim 31 merely recites a graphical user interface, which is software per se.
The additional elements are claimed to perform basic computer functions, such as presenting a user interface, presenting payment plan information, and modifying the payment plan information upon determining a payment has been received. The recitation of the computer elements amounts to mere instruction to implement an abstract concept on computers. According to the decision of Trading Technologies v. IBG LLC, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019), “arranging transactional information on a graphical user interface in a manner that assists traders in processing information more quickly” is not sufficient to show improvement in computer functionality or integrate an abstract concept into practical application. Similarly, the concept arranges payment information on a GUI in a manner that assists users in processing payment information more quickly. Moreover, unlike the claims in Core Wireless v. LG, which reduce computer resource usage by extracting information from applications without launching them, the GUI in the present application does not improve computer functionality. Rather, the present claims utilize existing GUI technology to arrange debt payment information for easier processing by users.
The present claims do not recite limitation that improve the functioning of computer, effect a physical transformation, or apply the abstract concept in some other meaningful way beyond generally linking the use of the abstract concept to a particular technological environment. As such, the present claims fail to integrate into a practical application.
Step 2B: The claims do not recite additional elements that amount to significantly more than the abstract idea.
As discussed earlier, independent claim 5 recites a display device and a processor as additional element. Dependent claims 7-15, 17-21, 24, 25 do not recite any other additional element. Independent claim 28 recites a memory, a processor, and a display device of a first device as additional elements. Independent claim 30 recites a non-transitory machine readable medium, a processor, and a display device of a first device as additional elements. Claim 31 merely recites a graphical user interface, which is software per se. The additional elements are claimed to perform basic computer functions, such as presenting a user interface, presenting payment plan information, and modifying the payment plan information upon determining a payment has been received. According to MPEP 2106.05(d), “performing repetitive calculations”, “receiving, processing, and storing data”, “electronically scanning or extracting data from a physical document”, “electronic recordkeeping”, “storing and retrieving information in memory”, and “receiving or transmitting data over a network, e.g., using the Internet to gather data” are considered well-understood, routine, and conventional functions of computer. The present claims do not improve the functioning of computer. Simply implementing the abstract idea on a generic computer or using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, the present claims are ineligible for patent.
Claim Rejection – 35 U.S.C. 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 5, 7-15, 17-21, 24, 25, 28, 30, and 31 is/are rejected under 35 U.S.C. 103 as being unpatentable over Diggdon et al. (Patent No.: US 10,460,379), in view of Zhu et al. (CN 110750558 A).
As per claim 5, Diggdon teaches a computer-implemented method comprising (see col 2 line 45 through col 3 line 8):
presenting, on a display device of a first device, a user interface for a user account with an online platform (see col 2 line 45 through col 3 line 8, “provide the user with a user interface, the user interface including debt payment data associated with the debt payment plan”; see col 6 line 45-55, “Bill payment logic 141 may enable users to pay one or more bills electronically and/or automatically…Automatic payments may be made periodically (e.g., on a monthly basis) should a user have a recurring payment of a single amount (e.g., a set of loan payment amount)”);
presenting, in the user interface, a second display object comprising a first user
selectable option to select a payment plan type from a set of payment plan types for the debt, wherein at least one of the payment plan types of the set is a combination payment plan comprising at least two different payment schedules (see col 2 line 45 through col 3 line 8, “determine an amount of debt owned by the user based on accessing the account data stored in the storage device; and establish a debt payment plan for the user configured to permit the user to pay off the amount of debt over a period of time”; see col 7 line 39-49, “debt management logic 148 may track one or more loans (e.g., personal loans, home loans, etc.) or payment obligations (e.g., credit card payments due, etc.) and assist a user in establishing a plan for reducing and/or eliminating one or more sources of debt…debt management logic 148 may assist users in consolidating debt, establishing and managing a debt payment plan, and monitoring the progress of a debt payment plan”; see col 21 line 22-64, “enable a user to provide one or more inputs regarding a debt payment plan, which may include one or more sources of debt. The debt payment plan may be intended to permit the user to pay off debt related to one or more accounts over a period of time by making periodic payments”);
determining, by a processor, a user selected combination payment plan from the set of payment plan types (see col 21 line 22-64, “generate a debt payment plan that includes periodic payments intended to pay off a user’s debt over a period of time”; see col 22 line 22-43, “Display 950 may provide a user with data and other information regarding a user’s historic, current and/or projected debt levels for one or more accounts (e.g., credit or loan accounts, etc.). An account selection option 956 may be used to select one or more accounts to be presented in display 950”); and
presenting, in the user interface, a third display object comprising a payment progress indicator, wherein the payment progress indicator comprises a first component representative of a first of the at least two different payment schedules of the combination payment plan and a second component representative of a second of the at least two different payment schedules of the combination payment plan (see col 7 line 39-49, “debt management logic 148 may assist users in consolidating debt, establishing and managing a debt payment plan, and monitoring the progress of a debt payment plan”; see col 21 line 65 through col 22 line 10, “debt management logic 148 may track the user’s progress in paying down one or more amounts of debt…as shown in FIG. 10A, a bar chart 510 may show a goal 514 that represents an amount of debt a user hopes to reduce the user’s current debt”; see col 22 line 22-57, “as shown in FIG. 10B, graph 952 includes a number of status bars 960 that each provide a historic debt level for a specific month, and a current status bar 962 that provides the current debt level”, and “the various status bars shown in FIG. 10 B may be shaded using different shading techniques, colors, etc., with each different shade representing a different source of debt (such that a single status bar may include a number of different shading types, each representing a different source of debt”; alternatively see FIG. 6F, item 912, 920, 922, prior art’s GUI may provide multiple progress indicators for tracking a plurality of financial goals, including the progress of debt payments), and
wherein the first component is distinct from the second component “debt management logic 148 may track one or more loans (see col 7 line 39-49, e.g., personal loans, home loans, etc.) or payment obligations (e.g., credit card payments due, etc.”; see col 21 line 22-64, “enable a user to provide one or more inputs regarding a debt payment plan, which may include one or more sources of debt. The debt payment plan may be intended to permit the user to pay off debt related to one or more accounts over a period of time by making periodic payments”); and
responsive to determining that a payment has been received, determining to which of a first payment schedule and a second payment schedule it relates; and modifying at least a portion of a respective first or second component to
indicate that the payment has been made (see col 7 line 39-49, “debt management logic 148 may assist users in consolidating debt, establishing and managing a debt payment plan, and monitoring the progress of a debt payment plan”; see col 14 line 41-53, “Upon the user moving one or more cash flows, cash flow planning logic 144 may update graph 302, including the account balances, to reflect the scheduled cash flows”; see col 21 line 65 through col 22 line 10, “debt management logic 148 may track the user’s progress in paying down one or more amounts of debt…as shown in FIG. 10A, a bar chart 510 may show a goal 514 that represents an amount of debt a user hopes to reduce the user’s current debt”; see col 22 line 22-43, “as shown in FIG. 10B, graph 952 includes a number of status bars 960 that each provide a historic debt level for a specific month, and a current status bar 962 that provides the current debt level”; prior art teaches tracking the progress of paying down one or more amounts of debt and presenting the result in status bars, it is implied that the status bars are dynamically updated when the computer system receives payment data).
Examiner notes however, Diggdon does not explicitly teach the user interface providing a first display object comprising a first user selectable option displaying an invoice or bill associated with a debt.
Zhu teaches presenting, on a display device of a first device, a user interface for a user account with an online platform, the user interface providing a first display object comprising a first user selectable option displaying an invoice or bill associated with a debt (see page 11, “In one embodiment of the invention, the current operating interface can include selecting an option of a plurality of loan document, selection the option of each debt bill comprises a corresponding document identification” and “according to the financial data corresponding to the document identifier of the query, displaying the corresponding debt bill detail interface, debt value debt bill detail interface may include debt receipts”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Diggdon with teaching from Zhu to include presenting, on a display device of a first device, a user interface for a user account with an online platform, the user interface providing a first display object comprising a first user selectable option displaying an invoice or bill associated with a debt. The modification would have been obvious, because it is merely applying a known technique (displaying bill associated with debt) to a known method (i.e., debt repayment management) ready to provide predictable result (i.e., provide user information related to debt).
Claim 6 is Canceled.
As per claim 7, Diggdon teaches wherein the first component and the second component comprises one or more elements, and wherein modifying the at least a portion of the respective first or second component representative to indicate that the payment has been made comprises adjusting an appearance of at least one of the one or more elements (see col 7 line 39-49, “debt management logic 148 may assist users in consolidating debt, establishing and managing a debt payment plan, and monitoring the progress of a debt payment plan”; see col 21 line 65 through col 22 line 10, “debt management logic 148 may track the user’s progress in paying down one or more amounts of debt…as shown in FIG. 10A, a bar chart 510 may show a goal 514 that represents an amount of debt a user hopes to reduce the user’s current debt”; see col 22 line 22-43, “as shown in FIG. 10B, graph 952 includes a number of status bars 960 that each provide a historic debt level for a specific month, and a current status bar 962 that provides the current debt level”; prior art teaches tracking the progress of paying down one or more amounts of debt and presenting the result in status bars, it is implied that the status bars are dynamically updated when the computer system receives payment data).
As per claim 8, Diggdon teaches wherein adjusting the appearance of at least one element comprises one or more of: (i) increasing or decreasing a size of the at least one element; (ii) changing a shape of the at least one element; (iii) changing a colour of the at least one element; and (iv) shading or hashing the at least one element (see col 22 line 22-57, “the various status bars shown in FIG. 10 B may be shaded using different shading techniques, colors, etc.”).
As per claim 9, Diggdon teaches wherein adjusting the appearance of at least one of the one or more elements comprises adjusting the appearance of the at least one of the one or more elements by an adjustment measure, and wherein the adjustment measure is reflective of a received payment relative to an overall amount of the debt (see col 7 line 39-49, “debt management logic 148 may assist users in consolidating debt, establishing and managing a debt payment plan, and monitoring the progress of a debt payment plan”; see col 21 line 65 through col 22 line 10, “debt management logic 148 may track the user’s progress in paying down one or more amounts of debt…as shown in FIG. 10A, a bar chart 510 may show a goal 514 that represents an amount of debt a user hopes to reduce the user’s current debt”; see col 22 line 22-43, “as shown in FIG. 10B, graph 952 includes a number of status bars 960 that each provide a historic debt level for a specific month, and a current status bar 962 that provides the current debt level”; prior art teaches tracking the progress of paying down one or more amounts of debt and presenting the result in status bars, it is implied that the status bars are dynamically updated when the computer system receives payment data).
As per claim 10, Diggdon teaches wherein the first component comprises a progressive bar and wherein modifying the appearance of the progressive bar comprises progressing a slider of the progressive bar from a first side of the progressive bar toward a second side of the progressive bar by the adjustment measure (see col 7 line 39-49, “debt management logic 148 may assist users in consolidating debt, establishing and managing a debt payment plan, and monitoring the progress of a debt payment plan”; see col 21 line 65 through col 22 line 10, “debt management logic 148 may track the user’s progress in paying down one or more amounts of debt…as shown in FIG. 10A, a bar chart 510 may show a goal 514 that represents an amount of debt a user hopes to reduce the user’s current debt”; see col 22 line 22-43, “as shown in FIG. 10B, graph 952 includes a number of status bars 960 that each provide a historic debt level for a specific month, and a current status bar 962 that provides the current debt level”; prior art teaches tracking the progress of paying down one or more amounts of debt and presenting the result in status bars, it is implied that the status bars are dynamically updated when the computer system receives payment data).
As per claim 11, Diggdon teaches wherein the at least one of the one or more elements of the second component comprises a single section indicative of a deposit payment (see col 16, line 11-40, “Line 776 tracks the historic and projected account balances for one or more specific accounts (selected via account selection option 762 and identified by account identifier 764) and provides indicators 778 for any days having account activity (deposits, payments, etc.)” and “a pop-up or other types of image 796 may be provided that identifies one or more transactions 798 (e.g., a mortgage payment, insurance payment, a deposit, etc.)”).
As per claim 12, Diggdon teaches wherein the at least one element of the first component comprises a single section indicative of a deposit payment (see col 16, line 11-40, “Line 776 tracks the historic and projected account balances for one or more specific accounts (selected via account selection option 762 and identified by account identifier 764) and provides indicators 778 for any days having account activity (deposits, payments, etc.)” and “a pop-up or other types of image 796 may be provided that identifies one or more transactions 798 (e.g., a mortgage payment, insurance payment, a deposit, etc.)”).
As per claim 13, Diggdon teaches wherein the at least one element of the first component comprises a plurality of elements, each element being a non-contiguous section, and each non-contiguous section being indicative of an instalment of a respective payment schedule of the first component (see abstract, “the debt payment plan including projected periodic debt payments determined based on the account data and the surplus cash flow amount for the user; see col 6 line 45-55, “Bill payment logic 141 may enable users to pay one or more bills electronically and/or automatically…Automatic payments may be made periodically (e.g., on a monthly basis) should a user have a recurring payment of a single amount (e.g., a set of loan payment amount)”; see col 21 line 35-51, “Screen display 500 may provide a total debt amount 508, and determine a periodic payment amount 509 (e.g., a monthly payment, etc.) and a time period 511 (e.g., a number of months, years, etc.) with in which total debt amount 508 may be paid off based on periodic payment amount 509”).
As per claim 14, Diggdon teaches wherein the at least one element of the second component comprises a plurality of elements, each element being a non-contiguous section, and each non-contiguous section being indicative of an instalment of a respective payment schedule of the second component (see abstract, “the debt payment plan including projected periodic debt payments determined based on the account data and the surplus cash flow amount for the user; see col 6 line 45-55, “Bill payment logic 141 may enable users to pay one or more bills electronically and/or automatically…Automatic payments may be made periodically (e.g., on a monthly basis) should a user have a recurring payment of a single amount (e.g., a set of loan payment amount)”; see col 21 line 35-51, “Screen display 500 may provide a total debt amount 508, and determine a periodic payment amount 509 (e.g., a monthly payment, etc.) and a time period 511 (e.g., a number of months, years, etc.) with in which total debt amount 508 may be paid off based on periodic payment amount 509”)..
As per claim 15, Diggdon teaches wherein the non-contiguous sections are:
(i) equally sized representing equally sized instalments; or (ii) different in size, representing respective differently sized instalments (see col 21 line 35-51, “Screen display 500 may provide a total debt amount 508, and determine a periodic payment amount 509 (e.g., a monthly payment, etc.) and a time period 511 (e.g., a number of months, years, etc.) with in which total debt amount 508 may be paid off based on periodic payment amount 509”).
Claim 16 is Canceled.
As per claim 17, Diggdon teaches determining, by the processor, a first due date associated with the first payment schedule of the combination payment plan and a second due date associated with the second payment schedule, wherein the first due date is a date by which a first portion of the debt as represented by the first component is due to be paid and the second due date is a date by which a second portion of the debt as represented by the second component is due to be paid (see col 6 line 45-55, a user may specify a payee to whom a payment is to be sent, the date on which the payment is to be sent, and the amount of payment…Automatic payments may be made periodically (e.g., on a monthly basis) should a user have a recurring payment of a single amount (e.g., a set loan payment amount)”; prior art can manage a plurality of debts and payment schedules with different due dates).
As per claim 18, Diggdon teaches wherein the second due date is later than the first due date (see col 6 line 45-55, a user may specify a payee to whom a payment is to be sent, the date on which the payment is to be sent, and the amount of payment…Automatic payments may be made periodically (e.g., on a monthly basis) should a user have a recurring payment of a single amount (e.g., a set loan payment amount)”; prior art can manage a plurality of debts and payment schedules with different due dates).
As per claim 19, Diggdon teaches determining, by the processor, a plurality of consecutive second intermittent due dates, wherein each second intermittent due date is a date by which an instalment of the second payment schedule is due to be paid, and wherein a latest of the second intermittent due dates corresponds to the second due date (see col 6 line 45-55, a user may specify a payee to whom a payment is to be sent, the date on which the payment is to be sent, and the amount of payment…Automatic payments may be made periodically (e.g., on a monthly basis) should a user have a recurring payment of a single amount (e.g., a set loan payment amount)”; prior art can manage a plurality of debts and payment schedules with different due dates).
As per claim 20, Diggdon teaches wherein the plurality of consecutive second intermittent due dates is determined based on a number of instalments to be made or a regular payment cycle (see col 6 line 45-55, a user may specify a payee to whom a payment is to be sent, the date on which the payment is to be sent, and the amount of payment…Automatic payments may be made periodically (e.g., on a monthly basis) should a user have a recurring payment of a single amount (e.g., a set loan payment amount)”; prior art can manage a plurality of debts and payment schedules with different due dates).
As per claim 21, Diggdon teaches wherein determining, by the processor, the first due date and the second due date comprises receiving as user inputs, the first due date and the second due date (see col 6 line 45-55, a user may specify a payee to whom a payment is to be sent, the date on which the payment is to be sent, and the amount of payment…Automatic payments may be made periodically (e.g., on a monthly basis) should a user have a recurring payment of a single amount (e.g., a set loan payment amount)”; prior art can manage a plurality of debts and payment schedules with different due dates).
Claim 22-23 are Canceled.
As per claim 24, Diggdon teaches responsive to determining that an overpayment or an underpayment has been made: determining a modified first and/or second payment schedule based on the overpayment or underpayment; and modifying at least a portion of the respective first and/or second component reflect the overpayment or underpayment (see col 20 line 26-43, “should a user be ahead of pace in reaching saving goal 408, option 414 may provide the user with other possible users for excess funds (e.g., such as paying down debt, saving for other, specific savings goals (e.g., such as a vacation, school tuition, etc.)”; also see col 21 line 52-64, “debt management logic 148 may access data stored in data storage system 128 and/or interface with one or more logic components such as budgeting logic 142 in order to generate a debt payment plan that includes periodic payments intended to pay off a user’s debt over a period of time…debt management logic 148 may access a budget and/or spending plan to identify, for example, surplus monthly cash flows, discretionary spending amounts, excess saving amounts, etc., usable to assist in payment of debt owned by a user”; see col 22 line 22-43, “as shown in FIG. 10B, graph 952 includes a number of status bars 960 that each provide a historic debt level for a specific month, and a current status bar 962 that provides the current debt level”; prior art teaches tracking the progress of paying down one or more amounts of debt and presenting the result in status bars, it is implied that the status bars are dynamically updated when the computer system receives payment data).
As per claim 25, Diggdon teaches wherein determining the modified first and/or second payment schedule based on the overpayment or underpayment comprising one or more of: (i) reducing or increasing an amount of a next instalment due by the amount of the overpayment; (ii) reducing or increasing an amount of one or more remaining instalment; (iii) reducing or increasing a frequency of future instalments; and/or (iv) reducing or increasing a number of future repayments (see col 20 line 26-43, “should a user be ahead of pace in reaching saving goal 408, option 414 may provide the user with other possible users for excess funds (e.g., such as paying down debt, saving for other, specific savings goals (e.g., such as a vacation, school tuition, etc.)”; also see col 21 line 52-64, “debt management logic 148 may access data stored in data storage system 128 and/or interface with one or more logic components such as budgeting logic 142 in order to generate a debt payment plan that includes periodic payments intended to pay off a user’s debt over a period of time…debt management logic 148 may access a budget and/or spending plan to identify, for example, surplus monthly cash flows, discretionary spending amounts, excess saving amounts, etc., usable to assist in payment of debt owned by a user”; see col 22 line 22-43, “as shown in FIG. 10B, graph 952 includes a number of status bars 960 that each provide a historic debt level for a specific month, and a current status bar 962 that provides the current debt level”; prior art teaches tracking the progress of paying down one or more amounts of debt and presenting the result in status bars, it is implied that the status bars are dynamically updated when the computer system receives payment data).
Claims 26-27 are Cancelled.
Claim 28 is rejected for the same reason as claim 5.
Claim 29 is Canceled.
Claims 30 and 31 are rejected for the same reason as claim 5.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAO FU whose telephone number is (571)270-3441. The examiner can normally be reached 9:00 AM - 6:00 PM PST.
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, Christine M Behncke can be reached at (571) 272-8103. 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.
/HAO FU/Primary Examiner, Art Unit 3695
JAN-2026