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, 3-8, 11-14, and 16-18 are currently pending. Claims 2 and 9 are canceled and Claim 18 is newly added in the Claims filed on March 12, 2026.
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, 3-8, 11-14, and 16-18 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, 3-8, 11-14, and 16-18 are within the four statutory categories. Claims 1, 3-8, 11, and 16-18 are drawn to a method for optimizing utilization of resources, which is within the four statutory categories (i.e. process). Claims 12-14 are drawn to a system for optimizing utilization of resources, which is within the four statutory categories (i.e. machine).
Prong 1 of Step 2A
Claim 1, which is representative of the inventive concept, recites: A method for optimized utilization of resources in a blockchain based healthcare network, comprising:
acquiring, by a management server, patient data from a plurality of device nodes and provider nodes associated with a plurality of patients, wherein the patient data includes Electronic Health Record (EHR) and vital information of each of the plurality of patients;
clustering, by the management server, the plurality of patients into a plurality of patient clusters based on the patient data including the EHR, demographic parameters, behavioral parameters. and the vital information of each of the plurality of patients;
computing, by the management server, an adherence score associated with at least one Key Performance Indicator (KPI) for each patient in a corresponding patient cluster of the plurality of patient clusters based on the EHR and the vital information of a corresponding patient included in a corresponding patient cluster of the plurality of patient clusters;
calculating, by each of the plurality of device nodes, a limited adherence score corresponding to each patient of the plurality of patients at specific time intervals on daily basis;
validating, by a controller of the blockchain based healthcare network, an accuracy of the calculated limited adherence score based on a comparison of the calculated limited adherence score with the adherence score computed by the management server;
distributing, by the management server, the computed adherence score to a plurality of payor nodes in the blockchain based healthcare network;
receiving, by the management server, wellness points corresponding to each patient of the plurality of patients from a plurality of payor nodes of the blockchain based healthcare network, wherein the wellness points are based on the computed adherence score;
allocating, by the management server, the received wellness points to the plurality of provider nodes and a respective device node associated with a corresponding patient of the plurality of patients;
moving, by the management server, at least one patient from a first cluster of the plurality of patient clusters to a second cluster of the plurality of patient clusters based on progression of the wellness points corresponding to the at least one patient;
recommending, by the management server, at least one provider node of the plurality of provider nodes from whom at least one patient in a specific cluster is moved out to other provider nodes of the plurality of provider nodes in the blockchain based healthcare network using a graphical user interface of a blockboard, wherein the graphical user interface includes at least one of a list of providers, a list of physicians, a list of healthcare coordinators, and other participants in the blockchain based healthcare network along with corresponding ratings, wherein the graphical user interface further includes at least one cluster of the plurality of patient clusters, a plurality of selection icons related to a provider type, a risk level of the at least one cluster, and adherence factors, and wherein the recommendation is based on a determination that the computed adherence score is less than a target level set by the payor nodes;
recommending, by the management server based on the computed adherence score, at least one resource among a plurality of resources to at least one device node for improvement in the adherence score
recommending, by the management server based on the computed adherence score, a risk profile of patients, and patient's levels of adherence with adherence parameters and criteria of the adherence parameters, and a specific cluster of the plurality of patient clusters along with an indication of the risk profile of patients in the specific cluster; and
sending, by the management server, alerts to a set of device nodes among the plurality of device nodes belonging to the specific cluster along with specific actions based on a determination that the specific cluster includes patients having a high-risk profile.
The underlined limitations as shown above, given the broadest reasonable interpretation, cover the abstract idea of a certain method of organizing human activities because they recite 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 acquiring patient data, clustering the patients based on the patient data, computing an adherence score for each patient based on EHR and vital data, calculating a limited adherence score for each patient, validating an accuracy of the calculated limited adherence score, distributing the adherence score to a plurality of payors, receiving wellness points for each patient based on an adherence score, allocating the received wellness points to providers, moving at least one patient from a first cluster to a second cluster based on progression of the wellness points, recommending at least one provider based on the patient clusters, recommending resources based on the adherence score to improve the adherence score, recommending a specific cluster of patients, and sending alerts to users of the specific cluster indicating that the cluster of patients includes patients having a high risk profile, recite following rules or instructions for recommending healthcare providers and resources), 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 12 is identical as the abstract idea for Claim 1, because the only difference between Claims 1 and 12 is that Claim 1 recites a method, whereas Claim 12 recites a system and its corresponding structural limitations.
Dependent Claims 3-8, 11, 13-14, and 16-18 include other limitations, for example, Claim 3 recites criteria for the limited adherence score, Claims 4-5 and 14 recite utilizing the wellness points to generate a blockboard that is indicative of the effectiveness of an entity, Claim 6 recites limitations further defining the contents of the patient data and adherence score, Claim 7 recites generating and storing patient data items, Claim 8 recites different modes for generating the patient data item, Claim 11 recites acquiring criteria for the adherence score, displaying a deviation chart, and generating an adherence snapshot based on user input against the criteria, Claim 13 recites the plurality of payors generating wellness points for each of the patients based on the computed adherence score and transmitting the wellness points in response to the distributed adherence scores, and Claims 16-17 recite calculating aggregation points for providers based on data transmission events, determining whether any response is received for a specific service, computing a Node Performance Factor for each provider based on the response and the aggregation points, determining whether the NPF is less than a threshold and eliminating providers who are lower than the threshold, 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. Additionally, any limitations in dependent Claims 3-8, 11, 13-14, and 16-18 not addressed above are deemed additional elements to the abstract idea, and will be further addressed below. Hence dependent Claims 3-8, 11, 13-14, and 16-18 are nonetheless directed towards fundamentally the same abstract idea as independent Claims 1 and 12.
Prong 2 of Step 2A
Claims 1 and 12 are not integrated into a practical application because the additional elements (i.e. the non-underlined limitations above – in this case, the management server, the API, IoT, Internet gateway, the various devices comprising the nodes themselves, the blockchain based healthcare network, the GUI comprising the blockboard), amount to no more than limitations which:
amount to mere instructions to apply an exception – for example, the recitation of the management server, the API, IoT, Internet gateway, the various devices comprising the nodes themselves, the blockchain based healthcare network, which amounts to merely invoking a computer as a tool to perform the abstract idea, e.g. see [0032]-[0036] of the as-filed Specification, see MPEP 2106.05(f);
generally link the abstract idea to a particular technological environment or field of use – for example, the claim language of an Electronic Health Record (EHR), vital information, and the blockchain being a healthcare network, amounts to limiting the abstract idea to the field of healthcare, see MPEP 2106.05(h); and/or
add insignificant extra-solution activity to the abstract idea – for example, the recitation of acquiring the patient data from the plurality of device nodes, which amounts to selecting a particular data source or type of data to be manipulated, see MPEP 2106.05(g).
Additionally, dependent Claims 3-8, 11, 13-14, and 16-18 include other limitations, but these limitations also amount to generally linking the abstract idea to a particular technological environment or field of use (e.g. the types of data in the EHR recited in dependent Claim 6, the generating and storing of the hash recited in dependent Claim 18), adding insignificant extra-solution activity to the abstract idea (e.g. the acquiring of the patient data item(s) recited in dependent Claim 8, the computing of the aggregation points and NPF based on the transmission/reception of data recited in dependent Claims 16-17), and/or do not include any additional elements beyond those already recited in independent Claims 1 and 12, and hence also do not integrate the aforementioned abstract idea into a practical application.
Hence Claims 1, 3-8, 11-14, and 16-18 do not include additional elements that integrate the judicial exception into a practical application.
Step 2B
Claims 1 and 12 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 management server, the API, IoT, Internet gateway, the various devices comprising the nodes themselves, the blockchain based healthcare network, the controller of the blockchain based healthcare network), as stated above, are directed towards no more than limitations that amount to mere instructions to apply the exception, generally link the abstract idea to a particular technological environment or field of use, and/or add insignificant extra-solution activity to the abstract idea, wherein the insignificant extra-solution activity comprises limitations which:
amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields, as demonstrated by:
The present Specification expressly disclosing that the structural additional elements are well-understood, routine, and conventional in nature:
[0032]-[0036] of the as-filed Specification discloses that the additional elements (i.e. the management server, the API, IoT, Internet gateway, the various devices comprising the nodes themselves, the blockchain based healthcare network) comprise a plurality of different types of generic computing systems;
Relevant court decisions: The following are examples of court decisions demonstrating well-understood, routine and conventional activities, e.g. see MPEP 2106.05(d)(II):
Receiving or transmitting data over a network, e.g. see Intellectual Ventures v. Symantec – similarly, the current invention receives patient data from device nodes, distributes the adherence score to payor nodes, receives wellness points from the payor nodes, and allocates the wellness points to provider nodes and devices nodes over a network, for example the Internet, e.g. see [0032] of the as-filed Specification;
Performing repetitive calculations, e.g. see Parker v. Flook, and/or Bancorp Services v. Sun Life – similarly, the current invention performs basic calculations (i.e. computing the aggregation points, the NPF, and determining whether or not the NPF is less than a threshold) and does not impose meaningful limits on the scope of the claims;
Storing and retrieving information in memory, e.g. see Versata Dev. Group, Inc. v. SAP Am., Inc. – similarly, the current invention recites storing the patient data at device nodes, and retrieving the patient data from the device nodes in order to ultimately determine the aggregation points and NPF, and to eliminate nodes that are less than the threshold NPF;
Dependent Claims 3-8, 11, 13-14, and 16-18 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 in the EHR recited in dependent Claim 6, the generating and storing of the hash recited in dependent Claim 18), receiving or transmitting data over a network (e.g. the acquiring of the patient data item(s) recited in dependent Claim 8), performing repetitive calculations (e.g. the additional calculations of the limited adherence score, the test and drug adherence score recited in dependent Claim 6, and the additional computing of the aggregation points and NPF recited in dependent Claims 16-17), electronic recordkeeping (e.g. the storing of the patient data items recited in dependent Claim 7), and/or do not recite any additional elements not already recited in independent Claims 1 and 12, and hence do not amount to “significantly more” than the abstract idea.
Hence, Claims 1, 3-8, 11-14, and 16-18 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, 3-8, 11-14, and 16-18 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Subject Matter Free From Prior Art
Claims 1, 3-8, 11-14, and 16-18 are not presently rejected under 35 U.S.C. 102 or 103, and hence would be in condition for allowance if amended to overcome the rejections presented under 35 U.S.C. 101. The following represents Examiner’s characterization of the most relevant prior art references and the differences between the present claim language and the prior art references in view of 35 U.S.C. 102 and/or 103:
With regards to 35 U.S.C. 102 and/or 103, the following represents the closest prior art to the claimed invention, as well as the differences between the prior art and the limitations of the presently claimed invention.
Examiner notes that, as presently amended, Claims 1 and 12 incorporate (now canceled) features from dependent Claims 2 and 9. Specifically, the features of moving a patient from one cluster to another cluster, recommending a provider using a GUI of a blockboard based on a determination that the adherence score is less than a target level set by payors from Claim 9, and the computation of the adherence score and the limited adherence score, the validation of the accuracy of the limited adherence score, and the receiving and allocating of the wellness points from Claim 2. Additionally, Claim 9 was indicated as reciting allowable subject matter/subject matter free from prior art in the Final Rejection mailed on April 3, 2025.
The combination of Tran, Wager, and Halperin was previously cited to teach the limitations of Claim 1 of the Claims filed on January 3, 2023, and a brief description of relevant features of each is as follows:
Tran (US 2018/0001184) teaches receiving various patient metrics from EMRs obtained from various patient and provider devices, and further teaches grouping patients based on a plurality of medical, appointment, and demographic data. Tran also teaches calculating a compliance metric that is indicative of the patient’s compliance with a prescribed medical treatment.
Wager (US 2005/0075904) teaches calculating a clinical ladder rating for a provider, receiving an input of provider information from the provider, calculating a weighted rating for the provider based on the input, comparing the calculated weighted rating to a threshold, and identifying providers whose ratings are above the threshold.
Halperin (US 2015/0164438) teaches collects various patient and clinician metrics including a response time of a clinician for a patient, and utilizing the response time to determine a score and corresponding ranking of the clinician based on the score.
Furthermore, Walker and Siedlecki were cited to teach the limitations of Claim 2 of the Claims filed on January 3, 2023 (as stated above, a portion of Claim 2 has been incorporated into Claims 1 and 12), and a brief description of relevant features of each is as follows:
Walker teaches monitoring a patient compliance data and transmitting the compliance data to an authentication server and subsequently to an insurer. Walker additionally teaches determining rewards based on the compliance, wherein the rewards may correspond to a provider, for example providing a free office visit.
Siedlecki teaches calculating compliance metrics based on patient input, and evaluating the compliance data to classify it into good, okay, or needing improvement categories, and further evaluates compliance trends over a particular time period.
Additionally, regarding the features of Claim 9 which are now incorporated into independent Claim 1, the most relevant prior art references are Johnson (US 2018/0000407), Williams (US 2008/0010097), and Cox (US 2017/0213005), and the relevant features of each are as follows:
Johnson teaches moving a patient from a first cluster of patients to a second cluster of patients based on a progression of wellness points of the patient. That is, Johnson teaches moving patients to different cohorts/clusters based on patient progress metrics.
Williams teaches listing healthcare providers as part of a provider network or a healthcare insurance company based on the provider satisfying a metric, for example a Risk Adjusted Cost Index (RACI). That is, Williams teaches recommending a provider by including the provider on a list, wherein the provider is placed on the list based on the provider satisfying the metric.
Cox teaches identifying non-compliant patient cohorts, identifying resources available to the patients in the cohorts, and further provides notifications to non-compliant patients. That is, Cox teaches recommending a cohort of non-compliant patients and resources that may be used for the non-compliant patients, as well as sending an alert to users for non-compliant patients. Additionally, Cox teaches a GUI for identifying patients that are part of a cohort of patients, wherein the GUI enables a user to search for a cohort of patients that satisfy various criteria.
Additionally, regarding the feature of recommending of the at least one provider node “using a graphical user interface of a blockboard, wherein the graphical user interface includes at least at least one of a list of providers, a list of physicians, a list of healthcare coordinators, and other participants in the blockchain based healthcare network…a plurality of selection icons related to a provider type, a risk level of the at least one cluster, and adherence factors,” this feature is taught by Galvin (US 2019/0050770). Galvin teaches generating a user interface (i.e. a blockboard) for a patient that includes a list of healthcare providers, wherein a provider from the list of providers may be selected according to various data including whether or not the provider is in-network (i.e. a type of provider).
However, before the effective filing date, it would not have been obvious to one ordinarily skilled in the art of healthcare to combine the prior art references of Tran, Wager, Halperin, Walker, Siedlecki, Johnson, Williams, Cox, and Galvin, because a combination of these references is not reasonably considered as combining prior art elements according to known methods to yield predictable results, simple substitution of one known element for another to obtain predictable results, use of known technique to improve similar devices (methods, or products) in the same way, applying a known technique to a known device (method, or product) ready for improvement to yield predictable results, “obvious to try” (i.e. choosing from a finite number of identified, predictable solutions, with a reasonable expectation of success), known work in one field of endeavor may prompt variations of it for use in either the same field or a different one based on design incentives or other market forces if the variations are predictable to one of ordinary skill in the art, and/or the aforementioned prior art references do not include some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to combine prior art reference teachings to arrive at the claimed invention. That is, before the effective filing date, it would not have been obvious to one of ordinary skill in the art to combine the limitations of Tran, Wager, Halperin, Walker, Siedlecki, Johnson, Williams, Cox, and Galvin.
The aforementioned references are understood to be the closest prior art. Various aspects of the present invention are known individually, but for the reasons disclosed above, the particular manner in which the elements are claimed, when considered as an ordered combination, distinguishes from the aforementioned references and hence the invention recited in the now-amended Claims 1 and 12 is not considered to be a non-novel and/or obvious variant of the inventions taught by the closest prior art references.
Response to Arguments
Applicant’s arguments, see Remarks, filed March 12, 2026, with respect to the rejections of Claims 1, 3-8, 11-14, and 16-18 under 35 U.S.C. 101 have been fully considered but are not persuasive.
Applicant first alleges that the present invention is patent eligible because it does not recite an abstract idea, specifically because it recites “a specific, machine-implemented scoring and verification pipeline with multiple distributed actors,” e.g. see pgs. 15-17 of the Remarks – Examiner disagrees.
The distributed nature of the claimed invention is not, in itself, dispositive in determining whether the claimed invention recites an abstract idea because the concept of distributed computing is not a technological solution to a technological problem – that is, the concept of “assigning functions to the appropriate entity” has existed since long before the advent of computer technology, and thus cannot properly be considered a technological improvement and/or an improvement to the computer itself. That is, an abstract idea is not transformed into patent eligible subject matter merely because its functions are executed by a plurality of disparate entities.
Similarly, the claimed invention is not deemed patent eligible merely because it recites metrics that are machine-generated and not tied to human discretion. As stated above, the calculations of the various metrics recite at least rules or instructions to be followed in order to ultimately provide recommendations and alerts to users that indicate the risk level of a patient, which is a certain method of organizing human activities.
Furthermore, even assuming, arguendo, that the claimed invention “improves the node performance factor (NPF) of all the computing nodes involved,” the aforementioned improvement is not an improvement to the computers themselves and/or a technological improvement, but rather represent improvements to the abstract idea of organizing human activities. That is, rather than improving the functions of the computer itself, for example increased flexibility, faster search times, and smaller memory requirements, the claimed invention, as presently claimed, improves the process of the calculations of patient/healthcare metrics and the process of providing alerts to patients, which, as stated above, represents an improvement to the abstract idea of organizing human activities, and an improvement to an abstract idea is not a technological improvement, e.g. see MPEP 2106.05(a)(II).
Applicants further allege that the claimed invention is patent eligible because it integrates any abstract idea into a practical application, specifically because it provides a technological improvement and recites functional constraints that govern the flow of transactions among payor, provider, and device nodes, e.g. see pgs. 17-19 of Remarks – Examiner disagrees.
Examiner asserts that, for the reasons stated above, the alleged improvements are not deemed technological improvements. Furthermore, even assuming, arguendo, that the claimed functions govern the flow of transactions, the transactions represent operations of payors and providers (i.e. organizing human activities). That is, the abstract idea is not integrated into a practical application merely by virtue of the claim reciting payor and provider “nodes” (i.e. any suitable computing device) rather than actual payors and providers.
Applicants further allege that the claimed invention is patent eligible because it amounts to significantly more than an abstract idea, specifically in that the claimed limitations, when considered as an ordered combination, are not well-understood, routine, conventional, and/or well-known in the art, e.g. see pgs. 19-21 of Remarks – Examiner disagrees.
Examiner initially notes that the requirements of 35 U.S.C. 101 are wholly distinct from those of 35 U.S.C. 102 and 103, and hence the novelty and/or non-obviousness of a claimed invention is not dispositive as to its patent eligibility, e.g. see MPEP 2106.05.
Additionally, the additional elements of the management server, the API, IoT, Internet gateway, the various devices comprising the nodes themselves, the blockchain based healthcare network do not represent an unconventional, not well-understood, not routine combination of additional elements because each of the aforementioned elements represent generic computer structure performing generic computer functions that are expected of each element. For example, [0032]-[0036] of the as-filed Specification discloses that the management server comprises a processor that is used to process the various data, the blockchain based healthcare network may comprise a plurality of various types of known networks interconnected, and the nodes comprise any suitable type of known computing device that is capable of communicating via the IoT, API, or Internet. In contrast to the invention of Bascom, where the ordered combination resulted in a system that was less susceptible to hacking and less dependent on local hardware and software, and that was more flexible than conventional technology, the additional elements of the claimed invention merely perform functions that each is expected to be capable of performing and, as stated above, do not achieve a technological improvement. Additionally, considering the additional elements as an ordered combination does not change the functionality nor the improvements achieved compared to when each of the additional elements are considered individually. Hence, the present invention, as presently claimed, does not recite significantly more than an abstract idea.
Additionally, specifically regarding newly added dependent Claim 18, the improvement of reducing the computing power required to process transactions on the blockchain and reducing the amount of transactions that need to be processed, e.g. see [0090] of the as-filed Specification, is not achieved as a result of the limitations as presently claimed in Claim 18. For example, as presently claimed, Claim 18 merely recites the generating of a single hash, and the storing of the generated single hash on the blockchain, while also claiming that this single hash “enables” nodes in the blockchain to validate transactions without re-validating patient data by the plurality of device nodes and reduces the computation power required. However, the aforementioned improvements disclosed in [0090] of the as-filed Specification are achieved by virtue of the limitations recited in [0087]-[0089] of the as-filed Specification, and Fig. 11 of the Drawings – specifically the “per day hash” incorporating a number of individual hashes (Hash 1, Hash 2,…Hash N), which are not claimed by Claim 18. Hence, the claimed subject matter of dependent Claim 18 does not reflect the specific features recited in [0087]-[0089] of the as-filed Specification that actually achieve the improvements recited in [0090] of the as-filed Specification. Therefore, as presently claimed, there is insufficient nexus between the claimed invention of Claim 18 and the purported improvements.
For the aforementioned reasons, Claims 1, 3-8, 11-14, and 16-18 are rejected under 35 U.S.C. 101.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN P GO whose telephone number is (703)756-1965. The examiner can normally be reached Monday-Friday 9am-6pm Pacific.
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/Primary Examiner, Art Unit 3681