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 .
Status of the Claims
Claims 1-20 are currently pending.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1
Claims 1-20 are within the four statutory categories. Claims 1-9 are drawn to a system for tracking changes in patient data, which is within the four statutory categories (i.e. machine). Claims 10-20 are drawn to a method for tracking changes in patient data, which is within the four statutory categories (i.e. process).
Prong 1 of Step 2A
Claim 1, which is representative of the inventive concept, recites:
A software-as-a-service (SaaS) system for determining specific calculated individual functional changes in the level of resources needed using unique identifiers within activities of daily living, community engagement, social participation, and educational environments, the system comprising:
an input interface configured to receive data collected from an individual user regarding previous capabilities identified by unique identifiers within specific functional domains including activities of daily living, community engagement, social participation, and educational activities;
wherein the input interface is configured to receive observed capability data provided by a trained professional corresponding to the unique identifiers;
a first database configured to store normative data comprising research-based datasets of functional levels corresponding to the unique identifiers within the specific functional domains;
a second database configured to store fee schedules, costs, aids, home modifications, resource time requirements of normal populations, and diagnosis-specific physical change expectations;
a processor configured to:
(a) associate the received individual data and professional data with the unique identifiers to map functional capabilities accurately;
(b) compare the individual data and the observed capability data to the normative data for each unique identifier to determine deviations from normative functional levels;
(c) calculate specific percentage losses or gains in function for the individual user for each unique identifier based on the comparison;
(d) determine the level of resource need by integrating the calculated functional changes with time components, resource requirements, and equipment needs corresponding to each unique identifier;
(e) generate an outcome report that includes the calculated percentage losses or gains, graphical representations of changes in function, and recommendations for resources, equipment, services, and treatments;
(f) project long-term changes in status, function, and resource requirements based on diagnosis-specific expectations;
an output interface configured to output the outcome report to authorized users.
The underlined limitations as shown above, given the broadest reasonable interpretation, recite the abstract idea of a mathematical concept and/or a certain method of organizing human activity because they recite mathematical relationships, formulas, equations, and/or mathematical calculations (in this case, the step of calculating the percentage losses or gains includes a mathematical calculation), and/or managing personal behavior or relationships or interactions between people (i.e. social activities, teaching, and following rules or instructions – in this case, the steps of collecting data from an individual user and a trained professional, storing various types of data, associating the data from the individual and the professional with unique identifiers, comparing the individual data and the professional data to normative data, calculating the losses or gains in function based on the comparison, determine a level of resource need, generating an outcome report, project long-term changes in status, function, and resource requirements, and outputting the outcome report includes following rules or instructions to diagnose a patient health status and forecast resource needs for the patient), e.g. see MPEP 2106.04(a)(2). Any limitations not identified above as part of the abstract idea are deemed “additional elements,” and will be discussed in further detail below.
Furthermore, the abstract idea for Claim 10 is identical as the abstract idea for Claim 1, because the only difference between Claims 1 and 10 is that Claim 1 recites a system, whereas Claim 10 recites a method.
Dependent Claims 2-9 and 11-20 include other limitations, for example Claims 2 and 13 recite types of identifiers, Claims 3 and 14 recite presenting questionnaires to individual users, Claims 4 and 15 recite combining the data provided by the individual user and the professional, Claims 5 and 16 recite applying a scoring process to the data provided by the individual user and the professional to determine resource need, Claims 6, 11, and 17 recite the contents of the outcome report, Claims 7 and 18 recite calculating needs based on time requirements and fee schedules, Claims 8, 12, and 19 recite determining the long-term change projection utilizing diagnosis normative data, and Claims 9 and 20 recite intended uses for the claimed invention, but these only serve to further narrow the abstract idea, and a claim may not preempt abstract ideas, even if the judicial exception is narrow, e.g. see MPEP 2106.04. Hence dependent Claims 2-9 and 11-20 are nonetheless directed towards fundamentally the same abstract idea as independent Claims 1 and 10.
Hence Claims 1-20 recite the aforementioned abstract idea.
Prong 2 of Step 2A
Claims 1 and 10 are not integrated into a practical application because the additional elements (i.e. the non-underlined limitations above – in this case, the input interface, the first and second databases, the processor, and the output interface) amount to no more than limitations which:
amount to mere instructions to apply an exception – for example, the recitation of the input and output interfaces, the first and second databases, and the processor, which amounts to merely invoking a computer as a tool to perform the abstract idea because the aforementioned limitations merely require the use of software to tailor information and provide it to the user on a generic computer, e.g. see MPEP 2106.05(f); and/or
generally link the abstract idea to a particular technological environment or field of use – for example, the claim language reciting the type of data being processed, which amounts to limiting the abstract idea to the field of healthcare, e.g. see MPEP 2106.05(h).
Additionally, dependent Claims 2-9 and 11-20 include other limitations, but these limitations also amount to no more than generally linking the abstract idea to a particular technological environment or field of use (e.g. the types of data recited in dependent Claims 2-3, 6, 8-9, 11-14, 17, and 19-20), and/or do not include any additional elements beyond those already recited in independent Claims 1 and 10 (e.g. the calculations recited in dependent Claims 4-5, 7, 15-16, and 18 also recite at least mathematical calculations), and hence also do not integrate the aforementioned abstract idea into a practical application.
Hence Claims 1-20 do not include additional elements that integrate the judicial exception into a practical application.
Step 2B
Claims 1 and 10 do not include additional elements that are sufficient to amount to “significantly more” than the judicial exception because the additional elements (i.e. the non-underlined limitations above – in this case, the input interface, the first and second databases, the processor, and the output interface), as stated above, are directed towards no more than limitations that amount to mere instructions to apply the exception, and/or generally link the abstract idea to a particular technological environment or field of use, wherein the additional elements comprise limitations which:
amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields, as demonstrated by:
Relevant court decisions: The limitations interpreted as additional elements are analogized to the following examples of court decisions demonstrating well-understood, routine and conventional activities, e.g. see MPEP 2106.05(d)(II):
Performing repetitive calculations, e.g. see Parker v. Flook, and/or Bancorp Services v. Sun Life – similarly, the additional elements recite performing basic calculations (i.e. calculating the percentage loss or gain) and does not impose meaningful limits on the scope of the claims;
Electronic recordkeeping, e.g. see Alice Corp v. CLS Bank – similarly, the additional elements merely recite the creating and maintaining of the data stored in the first and second databases;
Storing and retrieving information in memory, e.g. see Versata Dev. Group, Inc. v. SAP Am., Inc. – similarly, the additional elements recite storing various types of data in the first and second databases, and retrieving the data from storage in order to process the data and output the results of the processing via the outcome report;
Dependent Claims 2-9 and 11-20 include other limitations, but none of these limitations are deemed significantly more than the abstract idea because the additional elements recited in the aforementioned dependent claims similarly amount to generally linking the abstract idea to a particular technological environment or field of use (e.g. the types of data recited in dependent Claims 2-3, 6, 8-9, 11-14, 17, and 19-20), and/or do not include any additional elements beyond those already recited in independent Claims 1 and 10 (e.g. the calculations recited in dependent Claims 4-5, 7, 15-16, and 18 also recite at least mathematical calculations), and hence do not amount to “significantly more” than the abstract idea.
Hence, Claims 1-20 do not include any additional elements that amount to “significantly more” than the judicial exception.
Thus, taken alone, the additional elements do not amount to significantly more than the abstract idea identified above. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually, and there is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation.
Therefore, whether taken individually or as an ordered combination, Claims 1-20 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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-8 and 10-19 are rejected under 35 U.S.C. 103 as being unpatentable over Shlain (US 2013/0073306) in view of Koenig (US 2009/0099875).
Regarding Claim 1, Shlain teaches the following: A software-as-a-service (SaaS) system for determining specific calculated individual functional changes in the level of resources needed using unique identifiers within activities of daily living, community engagement, social participation, and educational environments, the system comprising:
an input interface configured to receive data collected from an individual user regarding previous capabilities identified by unique identifiers within specific functional domains including activities of daily living, community engagement, social participation, and educational activities (The system includes graphical user interfaces (GUIs) that receive input from patients (i.e. individual users), e.g. see Shlain Figs. 22-26 and 53, wherein the patient input includes an indication of various condition such as itchiness or the patient’s ability to eat or function (i.e. daily living), e.g. see Shlain [0191]-[0192], Table 1, Fig. 22, enables the patients to send and share messages with other patients suffering from the same or similar conditions (i.e. community engagement and social participation), e.g. see Shlain [0206], and provide the patient with educational information or care instructions, e.g. see Shlain [0078] and [0203].);
wherein the input interface is configured to receive observed capability data provided by a trained professional corresponding to the unique identifiers (The system includes GUIs that receive input from providers (i.e. trained professionals), e.g. see Shlain Figs. 2-21, 27, and 40-41, wherein the provider input includes confirmations that actions will be taken, e.g. see Shlain [0239], wherein the confirmations for actions may include actions to address the patient condition (i.e. daily living), follow-ups for patient instructions such as for exercises (i.e. educational activities), follow-up appointments, and/or posts from related parties for the patient (i.e. community engagement and social participation), e.g. see Shlain [0245], [0249]-[0251], and [0254], Figs. 47, 51-53.);
a first database configured to store normative data comprising research-based datasets of functional levels corresponding to the unique identifiers within the specific functional domains (The system stores Loops that comprise a plurality of codes and standards (i.e. normative data comprising research-based datasets) that define the patient protocols, e.g. see Shlain [0076] and [0153]-[0156], wherein the Loops and the data processed by the system as a whole may be stored on a storage device of a computer system and/or on a server (i.e. either of which may be interpreted as the first/second database), e.g. see Shlain [0067], [0076], and [0266]-[0268], Figs. 1A and 28.);
a second database configured to store fee schedules, costs, aids, home modifications, resource time requirements of normal populations, and diagnosis-specific physical change expectations (The Loops include coding for healthcare fees and costs, e.g. see Shlain [0153], home exercises, e.g. see Shlain Table 1, an overall time period for a Loop, e.g. see Shlain [0106], and an arc of recovery profile defining an evidence-based and population-based expected trajectory of the patient’s recovery, e.g. see Shlain [0075], wherein the Loops and the data processed by the system as a whole may be stored on a storage device of a computer system and/or on a server (i.e. either of which may be interpreted as the first/second database), e.g. see Shlain [0067], [0076], and [0266]-[0268], Figs. 1A and 28.);
a processor (The functions of the system are executed by at least one processor, e.g. see Shlain [0261].) configured to:
(a) associate the received individual data and professional data with the unique identifiers to map functional capabilities accurately (The system utilizes the patient inputs (i.e. the individual data) and the provider inputs (i.e. the professional data) regarding the patient condition (i.e. the data pertaining to the unique identifiers) to tack the patient progression regarding the condition, e.g. see Shlain [0076] and [0211].);
(b) compare the individual data and the observed capability data to the normative data for each unique identifier to determine deviations from normative functional levels (The system compares the patient inputs, the provider inputs, and the standardized protocols to determine the patient progress in relation to expected progress, e.g. see Shlain [0077]-[0078] and [0109].);
(d) determine the level of resource need by integrating the calculated functional changes with time components, resource requirements, and equipment needs corresponding to each unique identifier (The system determines patient needs, for example determining that a patient may need to see a specialist (i.e. a resource), e.g. see Shlain [0164], a timing/timeline for the patient needs (i.e. time components), e.g. see Shlain Fig. 53 and Table 1, or that a patient may need a specific type of medication, gauze, or crutches (i.e. equipment needs), e.g. see Shlain Table 1.);
(e) generate an outcome report that includes graphical representations of changes in function, and recommendations for resources, equipment, services, and treatments (The system generates a GUI displaying graphs (i.e. graphical representations of change) of patient metric progression over time, instructions for the patient to follow such as a recommendation to see a provider, for medicine, and ice packs (i.e. resources, equipment, services, and treatments), e.g. see Shlain [0158], Fig. 53.);
(f) project long-term changes in status, function, and resource requirements based on diagnosis-specific expectations (The constructed GUI enables patient or caregivers to understand long-term trends with respect to the patient’s care across a variety of metrics, e.g. see Shlain [0254], Fig. 53.);
an output interface configured to output the outcome report to authorized users (The system generates the GUI and provides it to users, e.g. see Shlain [0254], Fig. 53).
But Shlain does not teach and Koenig teaches the following:
(c) calculate specific percentage losses or gains in function for the individual user for each unique identifier based on the comparison (The system generates percent deficit (i.e. losses) and percent improvement (i.e. gains) for a patient based on a standard, e.g. see Koenig [0107]-[0112], [0129], [0131], and [0134].); and
wherein the outcome report includes the calculated percentage losses or gains (The system constructs screens (i.e. outcome reports) that show the percent deficit and percent improvement, Koenig Figs. 17-20, and 22).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify Shlain to incorporate calculating and displaying the percentage losses and percentage gains for the patient as taught by Koenig in order to provide users with actual objective measurements for the patient in a format that is easy to read and evaluate, e.g. see Koenig [0010].
Regarding Claim 2, the combination of Shlain and Koenig teaches the limitations of Claim 1, and Shlain further teaches the following:
The system of claim 1, wherein the unique identifiers comprise specific tasks or activities that uniquely identify functional capabilities and corresponding resource needs within the functional domains (The system receives data from the patient and the provider regarding various patient conditions such as the patient experiencing itchiness or the patient’s ability to perform tasks such as eating or sleeping and/or the patient’s ability to use crutches (i.e. resources), e.g. see Shlain Table 1.).
Regarding Claim 3, the combination of Shlain and Koenig teaches the limitations of Claim 1, and Shlain further teaches the following:
The system of claim 1, wherein the input interface presents questionnaires to the individual user formatted with prompts including, "Could you do the following?,""Did you do the following?," and "Were you responsible for the following?" to assess pre-injury or baseline capabilities accurately (The system prompts the patient for data regarding various patient conditions, for example the patient’s ability to perform certain tasks and what actions the patient has performed, e.g. see Shlain Table 1.).
Examiner further notes that the specific language claimed for the prompts represents non-functional descriptive material. Where the claim as a whole is directed conveying a message or meaning to a human reader independent of the intended computer system, and/or the computer-readable medium merely serves as a support for information or data, no functional relationship exists. For example, a claim to a memory stick containing tables of batting averages, or tracks of recorded music, utilizes the intended computer system merely as a support for the information. Such claims are directed toward conveying meaning to the human reader rather than towards establishing a functional relationship between recorded data and the computer. See MPEP 2111.05. In this case, the specific language of the prompts does not affect the functioning of the claim (i.e. the presentation of prompts to a patient) whatsoever, and hence does not impart any meaningful structure or functionality to the claimed invention of Claim 3, and hence the specific language/wording of the prompts is not afforded patentable weight.
Regarding Claim 4, the combination of Shlain and Koenig teaches the limitations of Claim 1, and Shlain further teaches the following:
The system of claim 1, wherein the processor combines the data collected from the individual user and the observed capability data provided by the trained professional to assess changes in functional levels more accurately (The system receives patient input (i.e. data from the individual user) and provider input (i.e. observed capability data from the trained professional), e.g. see Shlain [0191]-[0192] and [0245], wherein the received inputs are used to assess the patient progress, e.g. see Shlain [0220], [0224], [0235], and [0253].).
Regarding Claim 5, the combination of Shlain and Koenig teaches the limitations of Claim 4, and Shlain further teaches the following:
The system of claim 4, wherein the processor is configured to use the data collected from the individual user and the observed capability data and apply a scoring process to objectively assess and score the current status of the individual, integrate the score with the normative data and diagnosis data to perform priority data calculations for determining resource needs (The system analyzes the patient input (i.e. data from the individual user) and provider input (i.e. observed capability data), e.g. see Shlain [0191]-[0192] and [0245], wherein the received data may be objective data, e.g. see Shlain [0131], wherein the received inputs are used to assess the patient progress, e.g. see Shlain [0220], [0224], [0235], and [0253], and wherein the patient progress comprises a status displayed as a color coded icon and dictates suggested actions to be taken (i.e. resource needs), e.g. see Shlain [0219]-[0220].).
Regarding Claim 6, the combination of Shlain and Koenig teaches the limitations of Claim 1, and Shlain further teaches the following:
The system of claim 1, wherein the outcome report includes graphical representations to visually explain changes in function based on specific domains and subdomains (The system determines the patient progress and displays an indication of the patient progress as color coded icons, e.g. see Shlain [0219]-[0220].).
Regarding Claim 7, the combination of Shlain and Koenig teaches the limitations of Claim 1, and Shlain further teaches the following:
The system of claim 1, wherein the processor calculates required resources, services, equipment, and associated costs by integrating pre- and post-function time requirements and accessing current fee schedules from the database (The system determines the needs for the patient based on fees and healthcare codes indicative of various diagnoses and comorbidities, e.g. see Shlain [0153]-[0154], wherein the system may determine that the patient needs include a follow-up appointment (i.e. services) and/or crutches (i.e. resources and equipment), e.g. see Shlain [0153]-[0154] and Table 1.).
Regarding Claim 8, the combination of Shlain and Koenig teaches the limitations of Claim 1, and Shlain further teaches the following:
The system of claim 1, wherein the projection of long-term changes utilizes diagnosis-specific normative data to anticipate future functional changes and resource requirements (The system predicts a trend for the patient including an urgency of the predicted patient condition, e.g. see Shlain [0112], wherein the urgency of the patient condition may cause a provider to consider more rapid or a particular action for a patient in an urgent situation, e.g. see Shlain [0076].).
Regarding Claim 10, the limitations of Claim 10 are substantially similar to those claimed in Claim 1, with the sole difference being that Claim 1 recites a system, whereas Claim 10 recites a method. Specifically pertaining to Claim 10, Examiner notes that Shlain teaches a system and a method, e.g. see Shlain [0002], [0276], and [0281], and hence the grounds of rejection provided above for Claim 1 are similarly applied to Claim 10.
Regarding Claim 11, the combination of Shlain and Koenig teaches the limitations of Claim 10, and Shlain and Koenig further teach the following:
The method of claim 10, wherein the outcome report includes the calculated percentage losses or gains (The system constructs screens (i.e. outcome reports) that show the percent deficit and percent improvement, Koenig Figs. 17-20, and 22.); graphical representations to visually explain changes in function based on specific domains and subdomains (The system generates a GUI displaying graphs (i.e. graphical representations of change) of patient metric progression over time, instructions for the patient to follow such as a recommendation to see a provider, for medicine, and ice packs (i.e. resources, equipment, services, and treatments), e.g. see Shlain [0158], Fig. 53.); and recommendations for resources, equipment, services, and treatments (The system determines the patient progress and displays an indication of the patient progress as color coded icons, e.g. see Shlain [0219]-[0220].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify Shlain to incorporate calculating and displaying the percentage losses and percentage gains for the patient as taught by Koenig in order to provide users with actual objective measurements for the patient in a format that is easy to read and evaluate, e.g. see Koenig [0010].
Regarding Claim 12, the combination of Shlain and Koenig teaches the limitations of Claim 10, and Shlain further teaches the following:
The method of claim 10, further providing the step of projecting long-term changes in status, function, and resource requirements based on diagnosis-specific expectations (The constructed GUI enables patient or caregivers to understand long-term trends with respect to the patient’s care across a variety of metrics, e.g. see Shlain [0254], Fig. 53.).
Regarding Claims 13-19, the limitations of Claims 13-19 are substantially similar to those claimed in Claims 2-8, with the sole difference being that Claims 2-8 recite a system, whereas Claims 13-19 recite a method. Specifically pertaining to Claims 13-19, Examiner notes that Shlain teaches a system and a method, e.g. see Shlain [0002], [0276], and [0281], and hence the grounds of rejection provided above for Claims 2-8 are similarly applied to Claims 13-19.
Claims 9 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Shlain and Koenig in view of Chan (US 2020/0356952).
Regarding Claim 9, the combination of Shlain and Koenig teaches the limitations of Claim 1, and Shlain further teaches the following:
The system of claim 1, wherein the system is utilized for individual user baseline testing, periodic reassessments, and determination of resource requirements and disability payouts in medical legal cases (The system obtains patient data from the patient and from the provider (i.e. the first instance of obtaining the data is interpreted as a baseline), e.g. see Shlain [0078], [0191]-[0192], and [0245], and includes follow-up visits (i.e. periodic reassessments), e.g. see Shlain [0078] and [0108], patient needs, e.g. see Shalin [0076], and cost coding for patient conditions including the need for crutches, e.g. see Shlain [0153] and Table 1.).
But the combination of Shlain and Koenig does not teach and Chan teaches the following:
wherein the system is utilized for evaluations by government agencies to determine functional changes over time (The system labels the patient condition using a diagnosis code, wherein the code may be modified as the patient’s condition changes, wherein the diagnosis code determines the level of Medicare (i.e. a government agency) reimbursement, e.g. see Chan [0251].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify Shlain and Koenig to incorporate factoring in Medicare reimbursement corresponding to changing patient condition as taught by Chan in order to ensure accurate and timely clinical documentation, e.g. see Chan [0011].
Additionally, the limitations of Claim 9 are deemed statements of intended use. Statements of intended use raise a question as to the limiting effect of the language in the claims, e.g. see MPEP 2103(I)(C). That is, the intent of the limitation does not change/add any functions to the claim itself, because instead of positively reciting a function (e.g. determining testing to administer to establish a user baseline, government agencies evaluating functional changes over time, etc.), the aforementioned language merely recites a result of an undisclosed limitation (i.e. the system of claim 1 is used for the purpose of user baseline testing, evaluations by government agencies, etc.). As shown above, in the interest of compact prosecution, Examiner has afforded these limitations full patentable weight, but Claim 9 is nonetheless unpatentable over the cited references under 35 U.S.C. 103.
Regarding Claim 20, the limitations of Claim 20 are substantially similar to those claimed in Claim 9, with the sole difference being that Claim 9 recites a system, whereas Claim 20 recites a method. Specifically pertaining to Claim 20, Examiner notes that Shlain teaches a system and a method, e.g. see Shlain [0002], [0276], and [0281], and hence the grounds of rejection provided above for Claim 9 are similarly applied to Claim 20.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN P GO whose telephone number is (703)756-1965. The examiner can normally be reached Monday-Friday 9am-6pm 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, PETER H CHOI can be reached at (469)295-9171. 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.
/JOHN P GO/Examiner, Art Unit 3681