DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/10/25 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-4, 6-11, 13-18, and 20 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.
Claim Objections
Claims 2, 7, 9 and 14 are objected to because of the following informalities:
Claims 2 and 9, last two lines, describe, “determine the one or more alternate communication channels…” The examiner recommends, “determining the one or more alternate communication channels…”, in order to maintain consistency with the preamble and first two limitations.
Claims 7 and 14 describe “wherein the at least one processing device/the first apparatus is configured to: prompting […] receiving […] and executing […]” The examiner recommends, “wherein the at least one processing device/the first apparatus is configured to: prompt […] receive […] and execute […]”, in order to maintain consistency with the preamble.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6-11, 13-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mason (US 8,311,942), hereinafter “Mason”, in view of Kothuvatiparambil et al. (US 9,936,072), hereinafter “Kothuvatiparambil”.
RE claims 1, 8, and 15, Mason describes a system, computer program product, and method for dynamic communication channel modelling using machine learning algorithms, the computer program product comprising a non-transitory computer-readable medium comprising code causing a first apparatus to/the system/computer program product/method comprising:
at least one non-transitory storage device (FIG. 7 and col. 14 lns. 20-31: “storage device (506)”); and
at least one processing device coupled to the at least one non-transitory storage device (FIG. 7 and col. 14 lns. 20-31: “one or more processor(s) (502)”), wherein the at least one processing device is configured to:
continuously monitor, using communication channel modelling algorithm, one or more incoming natural language inputs received by the user, via a user input device, from one or more third parties (See col. 7 ln. 45 – col. 8 ln. 39: “FIG. 2 shows a flowchart for the bill payment widget to facilitate the payment of the bill in one or more embodiments of the invention. In Step 201, an email application detects a new email. Specifically, a new email directed to the email address of the user is added to the email account. The new email may be an irrelevant email or a bill notification email. In response to detecting the new email, the email application initiates the bill payment widget in Step 203. Specifically, the email application starts the bill payment widget to process the email in one or more embodiments of the invention.”
Also see col. 3 lns. 15-27: “In general, embodiments of the invention provide a method and system for paying bills based on bill notification emails. A bill notification email is an email from the biller sent to the user's email account that notifies the user of the existence of a bill from the biller. The user's email account may receive and therefore include bill notification emails intermixed with irrelevant emails. An irrelevant email is any email that is not a bill notification email. For example, irrelevant emails include business related emails, personal emails (e.g., from friends), advertisements, spam emails, newsletters, any other type of email. Embodiments of the invention identify, from the user's emails, which emails are bill notification emails. When bill notification email is identified, bill information including a payment amount and the biller identifier are obtained from the bill notification email. Using the payment amount and the biller identifier extracted from the bill notification email, the bill is paid for the user.”);
detect, using the communication channel modelling algorithm installed on a user input device, a natural language input from a third party to a user (See col. 7 ln. 45 – col. 8 ln. 39: “FIG. 2 shows a flowchart for the bill payment widget to facilitate the payment of the bill in one or more embodiments of the invention. In Step 201, an email application detects a new email. Specifically, a new email directed to the email address of the user is added to the email account. The new email may be an irrelevant email or a bill notification email. In response to detecting the new email, the email application initiates the bill payment widget in Step 203. Specifically, the email application starts the bill payment widget to process the email in one or more embodiments of the invention.”);
parse, using the communication channel modelling algorithm, the natural language input (See col. 7 ln. 55 – col. 8 ln. 9: “In Step 205, the bill payment widget scans the email to determine whether the email is a bill notification email and to gather the bill information from the email. One method for the bill payment widget to extract the bill information is to perform data scraping. Data scraping is a technique for extracting data from human-readable format. In one or more embodiments of the invention, the bill payment widget may use common keywords and key phrases to obtain the bill information. For example, when the bill payment widget identifies a phrase "due date" or "by" in the same sentence or adjacent to a common syntactical representation of a date (e.g., "9/24/2010", "September 24, 2010", "24 Sept 2010"), the bill payment widget may identify the date as the due date.”);
determine, based on at least the parsing, an expression pattern associated with the natural language input, (See col. 7 ln. 55 – col. 8 ln. 9: “In Step 205, the bill payment widget scans the email to determine whether the email is a bill notification email and to gather the bill information from the email. One method for the bill payment widget to extract the bill information is to perform data scraping. Data scraping is a technique for extracting data from human-readable format. In one or more embodiments of the invention, the bill payment widget may use common keywords and key phrases to obtain the bill information. For example, when the bill payment widget identifies a phrase "due date" or "by" in the same sentence or adjacent to a common syntactical representation of a date (e.g., "9/24/2010", "September 24, 2010", "24 Sept 2010"), the bill payment widget may identify the date as the due date.”
Also see col. 8 lns. 10-30: “Another method for the bill payment widget to extract the bill information is to use a template defined for the particular biller. Specifically, each biller may have a form email that the biller sends to all of the biller's customers. The form email may be used to derive a template for the particular biller. The template may have static portions and dynamic portions. The static portions are the text that is generic to multiple customers of the biller. The dynamic portions includes the bill information that is specific to the particular customer. The template may be stored in a data repository of templates for billers. Accordingly, to extract the bill information, the biller is identified (e.g., by using the email address from which the bill notification email was sent, by using text in the bill notification email, etc.) and used to obtain the template corresponding to the biller. Based on the template, the location of the dynamic portions of the email are identified and the type of bill information (e.g., biller, amount, due date, etc.) in the locations are identified. Thus, from the identified locations, the bill information is extracted and each component of the bill information is associated with the corresponding type of bill information.”);
identify keywords from the natural language input to summarize a main idea of the natural language input, wherein the main idea comprises at least instructions to initiate a resource transfer to a third party via a first communication channel associated with the third party (See col. 7 ln. 55 – col. 8 ln. 9: “In Step 205, the bill payment widget scans the email to determine whether the email is a bill notification email and to gather the bill information from the email. One method for the bill payment widget to extract the bill information is to perform data scraping. Data scraping is a technique for extracting data from human-readable format. In one or more embodiments of the invention, the bill payment widget may use common keywords and key phrases to obtain the bill information. For example, when the bill payment widget identifies a phrase "due date" or "by" in the same sentence or adjacent to a common syntactical representation of a date (e.g., "9/24/2010", "September 24, 2010", "24 Sept 2010"), the bill payment widget may identify the date as the due date.”);
extract, from the expression pattern, information associated with the third party and information associated with the resource transfer (col. 8 lns. 40-57: “In Step 207, a determination is made whether sufficient bill information exists in the email in one or more embodiments of the invention. If the email is an irrelevant email, then sufficient bill information does not exist in the email. In one or more embodiments of the invention, the amount of bill information is a function of the amount of pre-email existing information that the bill payment service or the bill payment widget has. For example, if the bill payment widget or the bill payment service is preconfigured with the user's account number of the user's account managed by the biller, then sufficient bill information may include only a payment due date, an amount, and an identifier of the biller.”);
determine one or more alternate communication channels for the user to initiate the resource transfer to the third party based on the information associated with the third party and the information associated with the resource transfer (See col. 9 lns. 24-49: “In Step 215, if a determination is made not to automatically send the bill payment information, then a network protocol request is generated that includes the bill information. In one or more embodiments of the invention, the generated network protocol address may include a uniform resource locator (URL). The domain in the URL may be the domain of the financial institution or the financial institution. Further, the URL may include a user identifier and an identifier of the bill payment service in one or more embodiments of the invention. The network protocol request payload may include bill information, such as the payment amount, the due date, biller identifier, and any other bill information in one or more embodiments of the invention.
In Step 217, the bill notification email is augmented with a selectable interface component having the network protocol request to create a modified bill notification email. Augmenting the bill notification email may include embedding the selectable interface component in the body of the bill notification email in one or more embodiments of the invention. Alternatively or additionally, the selectable interface component may be added or enabled to be presented next to the email in the graphical user interface of the email application. For example, the selectable interface component may be a GUI button, the URL, or any other feature that the user may select. After the bill notification email is augmented with the selectable interface component, the user may view the email.”
Also see col. 13 lns. 27-49: “In the example, the selectable interface component includes a network protocol request. Specifically, the bill payment widget may include as part of the selectable interface component the URL: http://services.banking.mybank.com/{customerId}/billPayment
In the above URL, services.banking.mybank.com is a domain for the financial institution, {customerld} is a unique identifier for the financial institution to identify the customer, and billPayment is the location of the bill payment service. In addition to the above, the bill information (payee=SCE, bill amount=$356.77, and due date=09/13/2010) is added to the payload of the network protocol request. Thus, as shown in the example, the information required to pay the bill is a part of the network protocol request.”);
transmit control signals configured to cause the user input device to display the one or more alternate communication channels (See col. 13 lns. 50-61: “If the user credentials are correct, then the bill payment service presents the user with the bill and the payment parameters as shown in FIG. 6D. Specifically, FIG. 6D, shows a single bill interface (412) presented to the user when the user selects a selectable interface component from a modified bill notification email and correctly submits the user's authentication credentials. As shown in the example, the user may view the payee, the due date, and the payment amount. Further, in one or more embodiments of the invention, the user may change any of the components. For example, the user may decide to only pay part of the billed amount or pay the bill on a different date. After reviewing the bill, the user selects the confirm button to confirm payment of the bill in the single bill interface (412). Upon receiving the selection of the confirm button, the bill payment service schedules payment of the bill.”);
electronically receive, via the user input device, a user selection of at least one of the one or more alternate communication channels (See col. 13 lns. 61-63: “After reviewing the bill, the user selects the confirm button to confirm payment of the bill in the single bill interface (412).”); and
execute the resource transfer to the third party via the at least one of the one or more alternate communication channels selected by the user (See col. 13 lns. 63-65: “Upon receiving the selection of the confirm button, the bill payment service schedules payment of the bill.”).
Mason doesn’t describe a system or method wherein the expression pattern is a derivation tree representing textual elements of the natural language input.
However, Kothuvatiparambil describes a system and method configured to:
determine, based on at least the parsing, an expression pattern associated with the natural language input, wherein the expression pattern is a derivation tree representing textual elements of the natural language input (See col. 4 lns. 47-60: “Automated response tool 120 generates a parse tree 145 based on the detected words 140. Parse tree 145 is a data structure that allows automated response tool 120 to accurately analyze call 135. For example, parse tree 145 may indicate the various language structures, such as clauses, phrases, subjects, verbs, and objects in a spoken statement and identify the words in each language structure. Automated response tool 120 may analyze parse tree 145 to determine the intent of a caller and also to determine any parameters provided by the caller for an invoked service. Automated response tool 120 may invoke a service based on its analysis of parse tree 145. Automated response tool 120 may also supply the invoke service with any parameters detected in parse tree 145.”
Also see col. 5 ln. 59-col. 6 ln. 2: “Language processor 205 may generate a parse tree 145 based on the detected words 140. Parse tree 145 may indicate the language structure of spoken statement 215. Using the previous example, parse tree 145 may indicate a verb and infinitive combination of “want” and “to pay” and an object of “bill” with the modifiers of “June” and “internet.” Language processor 205 may analyze parse tree 145 to determine the intent of the caller. For example, based on the example parse tree 145, language processor 205 may determine that the caller wants to pay a bill. In response, language processor 205 may invoke a bill pay service 220.”); [and]
extract, from the expression pattern, information associated with the third party and information associated with the resource transfer (See col. 6 lns. 3-10: “Language processor 205 may also determine from parse tree 145 that “bill” is modified by “June” and “internet.” Language processor 205 may extract “June” and “internet” as values for parameters 225 (e.g. date and type parameters) to the bill pay service 220. The values of the parameters 225 may be “June” and “internet.” Language processor 205 may then forward the determined service 220 and the values of the parameters 225 to service invoker 210.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in Mason a system and method wherein the expression pattern is a derivation tree representing textual elements of the natural language input, as taught by Kothuvatiparambil, in order to conserve processor resources while determining a user’s intent quickly and accurately (Kothuvatiparambil: col. 2 lns. 48-57).
RE claims 2, 9, and 16, Mason doesn’t describe but Kothuvatiparambil describes the system of claim 1, computer program product of claim 8, and method of claim 15, wherein determining the one or more alternate communication channels further comprises:
retrieving, from a data repository, one or more identifiers associated with a plurality of alternate communication channels (See col. 7 lns. 46-61: “Invoker 405 receive parse tree 145 and analyzes parse tree 145 to determine a service 220 to invoke to respond to spoken statement 215. Invoker 405 may analyze parse tree 145 to determine one or more potential services 415 to be invoked to respond to spoken statement 215. In some embodiments, the one or more potential services 415 may be all the services that can be invoked by automated response tool 120. Invoker 405 analyzes parse tree 145 to determine a confidence score 420 for each potential service 415. Confidence score 420 represents the likelihood that the corresponding potential service 415 is the service to be invoked to respond to spoken statement 215. Invoker 405 may compare the confidence scores 420 of each potential service 415 to determine which potential service 415 to invoke. For example, invoker 405 may invoke the potential service 415 with the highest confidence score 420.”);
determining a similarity index between the expression pattern and the one or more identifiers (See col. 7 ln. 62-col. 8 ln. 7: “Invoker 405 may determine confidence scores 420 based on the words and the structure of the words indicated by parse tree 145. For example, if parse tree 145 includes the words “pay” and “bill,” then a bill pay service may be assigned a high confidence score. As another example, if parse tree 145 includes the words “cancel” and “service,” then the bill pay service may not be assigned a high confidence score. Invoker 405 may employ machine learning processes to learn which words in parse tree 145 and which structures in parse tree 145 correspond with which potential service 415. As a result, invoker 405 may be trained to accurately assign confidence scores to potential services 415.”
Also see col. 8 lns. 18-26: “In particular embodiments, calculating the confidence score 420 for each potential service may include determining a distance between nodes. For example, the words indicated by parse tree 145 may be mapped to a node. Each potential service 415 may also be mapped to a second node. The confidence score 420 for that potential service 415 may be based on the distance between the node for parse tree 145 and the node for that potential service 415. The greater the distance, the lower the confidence score 420 may be.”); and
determin[ing] the one or more alternate communication channels from the plurality of alternate communication channels based on at least the similarity index (col. 8 lns. 7-17: “After determining service 220, invoker 405 may communicate service 220 to be invoked. An example algorithm for invoker 405 is as follows: wait for parse tree 145; receive parse tree 145; compare the words and structures in parse tree 145 with learned algorithms to determine confidence scores 420 for each potential service 415 of a plurality of potential services 415; compare the determined confidence scores and select the potential service 415 with the highest confidence score 420; and communicate the selected service for invocation.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in Mason a system and method wherein determining the one or more alternate communication channels further comprises: retrieving, from a data repository, one or more identifiers associated with a plurality of alternate communication channels; determining a similarity index between the expression pattern and the one or more identifiers; and determin[ing] the one or more alternate communication channels from the plurality of alternate communication channels based on at least the similarity index, as taught by Kothuvatiparambil, in order to more accurately identify the biller described in each received email through a method of evaluating the similarity between each biller and the content of the email.
RE claims 3, 10, and 17, Mason doesn’t describe but Kothuvatiparambil describes the system of claim 2, computer program product of claim 9, and method of claim 16, wherein determining the similarity index further comprises:
initiating a semantic text matching algorithm on the expression pattern and the one or more identifiers (See col. 8 lns. 18-26: “In particular embodiments, calculating the confidence score 420 for each potential service may include determining a distance between nodes. For example, the words indicated by parse tree 145 may be mapped to a node. Each potential service 415 may also be mapped to a second node. The confidence score 420 for that potential service 415 may be based on the distance between the node for parse tree 145 and the node for that potential service 415. The greater the distance, the lower the confidence score 420 may be.”);
extracting, using the semantic text matching algorithm, semantic primitives associated with the expression pattern and semantic primitives associated with the one or more identifiers (See col. 8 lns. 26-33: “In some embodiments, calculating confidence scores 420 for each potential service 415 may include comparing parse tree 145 with a parse tree corresponding to potential service 415. For example, the words and the structures of these parse trees may be compared to determine confidence score 420. For example, the more similar the parse trees are to each other the higher confidence score 420 may be.”);
determining a match between the semantic primitives associated with the expression pattern and the semantic primitives associated with the one or more identifier (See col. 8 lns. 26-33: “In some embodiments, calculating confidence scores 420 for each potential service 415 may include comparing parse tree 145 with a parse tree corresponding to potential service 415. For example, the words and the structures of these parse trees may be compared to determine confidence score 420. For example, the more similar the parse trees are to each other the higher confidence score 420 may be.”); and
determining, using the semantic text matching algorithm, the similarity index between the expression pattern and the one or more identifiers based on at least the matching (See col. 7 ln. 62-col. 8 ln. 8L “Invoker 405 may determine confidence scores 420 based on the words and the structure of the words indicated by parse tree 145. For example, if parse tree 145 includes the words “pay” and “bill,” then a bill pay service may be assigned a high confidence score. As another example, if parse tree 145 includes the words “cancel” and “service,” then the bill pay service may not be assigned a high confidence score. Invoker 405 may employ machine learning processes to learn which words in parse tree 145 and which structures in parse tree 145 correspond with which potential service 415. As a result, invoker 405 may be trained to accurately assign confidence scores to potential services 415. After determining service 220, invoker 405 may communicate service 220 to be invoked.”).
See the rejection of claim 2 for rationale to modify Mason based on the teachings of Kothuvatiparambil, as it is equally applicable here.
RE claims 4, 11, and 18 Mason describes the system of claim 1, computer program product of claim 8, and method of claim 15, wherein the at least one processing device is further configured to:
provide the communication channel modelling algorithm for installation on the user input device, wherein the communication channel modelling algorithm is configured to run continuously in a background of the user input device (See FIG. 1 Email Application 104 and Bill Payment Widget 106. Also see col. 5 lns. 7-47: “In one or more embodiments of the invention, an email application (104) is connected to the network. The email application (104) may correspond to a client application, a server application, or a combination thereof. For example, the email application (104) may execute locally on a user's device. Alternatively, the email application (104) may execute on a server. In one or more embodiments of the invention, the email application (104) is configured to provide emails (e.g., bill notification emails, irrelevant emails) to the user […] if the email application is a client application, the email application includes functionality to obtain emails from the user's email account and manage the user's emails by executing locally, on the user's device.
In one or more embodiments of the invention, regardless of whether the email application is a client application or a server application, the email application (104) optionally includes a bill payment widget (106) and/or an auto-forward widget (108). In one or more embodiments of the invention, the bill payment widget (106) and the auto-forward widget (108) is software code. In one or more embodiments of the invention, either or both widgets (e.g., bill payment widget (106), auto-forward widget (108)) may be a native component of the email application (104), an optional feature of the email application (104), a plug-in to the email application (104), or have another relationship with the email application.
In one or more embodiments of the invention, a bill payment widget (106) includes functionality to scan emails and determine whether the email is a bill notification email that includes sufficient bill information to pay the bill based on the bill notification email. Specifically, the bill payment widget (106) includes functionality to differentiate between irrelevant emails that are not bill notifications (e.g., emails from friends, family, colleagues, marketing departments, etc.) from bill notification emails.”).
RE claims 6, 13, and 20, Mason describes the system of claim 1, computer program product of claim 8, and method of claim 15, wherein executing the resource transfer to the third party via the at least one of the one or more alternate communication channels selected by the user further comprises:
triggering a proprietary resource transfer application on the user input device in response to receiving the user selection of at least one of the one or more alternate communication channels (See col. 13 lns. 50-61: “If the user credentials are correct, then the bill payment service presents the user with the bill and the payment parameters as shown in FIG. 6D. Specifically, FIG. 6D, shows a single bill interface (412) presented to the user when the user selects a selectable interface component from a modified bill notification email and correctly submits the user's authentication credentials. As shown in the example, the user may view the payee, the due date, and the payment amount. Further, in one or more embodiments of the invention, the user may change any of the components. For example, the user may decide to only pay part of the billed amount or pay the bill on a different date. After reviewing the bill, the user selects the confirm button to confirm payment of the bill in the single bill interface (412). Upon receiving the selection of the confirm button, the bill payment service schedules payment of the bill.”); and
automatically populating, on a graphical user interface of the proprietary resource transfer application, the information associated with the third party and the information associated with the resource transfer (See col. 13 lns. 50-61: “If the user credentials are correct, then the bill payment service presents the user with the bill and the payment parameters as shown in FIG. 6D. Specifically, FIG. 6D, shows a single bill interface (412) presented to the user when the user selects a selectable interface component from a modified bill notification email and correctly submits the user's authentication credentials. As shown in the example, the user may view the payee, the due date, and the payment amount. Further, in one or more embodiments of the invention, the user may change any of the components. For example, the user may decide to only pay part of the billed amount or pay the bill on a different date. After reviewing the bill, the user selects the confirm button to confirm payment of the bill in the single bill interface (412). Upon receiving the selection of the confirm button, the bill payment service schedules payment of the bill.”).
RE claims 7 and 14, Mason describes the system of claim 6 and computer program product of claim 13, wherein the at least one processing device is further configured to:
prompt, via the graphical user interface, the user to select at least one resource repository as a source of the resource transfer (See col. 11 lns. 56-65: “In Step 275, a selection of a bill is received from the user. For example, the user may select the input fields associated with various bills and then select a submit button. In addition to selecting the bills, the user may provide non-default preferences for paying the bill. For example, the non-default preferences may include the financial account to pay the bill, the mode to pay the bill, the amount, and the payment date. Based on the selection, the bills are paid according to the user preferences. Paying the bills may be performed as discussed above with reference to Step 235 in FIG. 3.”);
receive, via the graphical user interface, a user selection of the at least one resource repository (See col. 11 lns. 56-65: “In Step 275, a selection of a bill is received from the user. For example, the user may select the input fields associated with various bills and then select a submit button. In addition to selecting the bills, the user may provide non-default preferences for paying the bill. For example, the non-default preferences may include the financial account to pay the bill, the mode to pay the bill, the amount, and the payment date. Based on the selection, the bills are paid according to the user preferences. Paying the bills may be performed as discussed above with reference to Step 235 in FIG. 3.”); and
execute, using the proprietary resource transfer application, the resource transfer to the third party via the at least one of the one or more alternate communication channels selected by the user (See col. 11 lns. 56-65: “In Step 275, a selection of a bill is received from the user. For example, the user may select the input fields associated with various bills and then select a submit button. In addition to selecting the bills, the user may provide non-default preferences for paying the bill. For example, the non-default preferences may include the financial account to pay the bill, the mode to pay the bill, the amount, and the payment date. Based on the selection, the bills are paid according to the user preferences. Paying the bills may be performed as discussed above with reference to Step 235 in FIG. 3.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Chen (CN 105630839 A), especially at paragraphs [0060]-[0061], [0064]-[0065], [0070]-[0078], and [0083]-[0086].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Daniel C Washburn whose telephone number is (571)272-5551. The examiner can normally be reached Monday-Friday 9:00 am - 5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Daniel C Washburn can be reached at 571-272-5551. 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.
/DANIEL C WASHBURN/Supervisory Patent Examiner, Art Unit 2657