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 .
Priority
Applicant’s claim for the benefit of a prior-filed applications, 18/893,819, 18/357,031, and 60/414,831 under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
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 an abstract idea without significantly more.
Step 2A Prong One
Claims 1, 18, and 20 (claim 1 representative) recite provide patient information of a patient for a non-enrollment transaction; transmitting an indication of the non-enrollment transaction, the non-enrollment transaction being implemented, the non-enrollment transaction including patient identifying information, partner identifying information to identify the partner, practice identifying information to identify the healthcare practice, and a therapy identifier; receiving a first responsive indication indicating that the patient is not enrolled in a patient services program offered by the partner; provide patient enrollment information for an enrollment transaction; transmitting the patient enrollment information; receiving a second responsive indication indicating that the patient is enrolled; and resubmitting the non-enrollment transaction to retransmit the indication of the non-enrollment transaction to proceed with the non-enrollment transaction.
These limitations, as drafted, given the broadest reasonable interpretation, encompass managing interactions between people, which is a subgrouping of Certain Methods of Organizing Human Activity. For example, the claims encompass providing a non-enrollment transaction including patient ID, partner ID, practice ID, and therapy ID, receiving a response that the patient is not enrolled in a patient service program offered by the partner, presenting patient enrollment information to a user of a healthcare practice, transmitting the patient enrollment information, receiving a second indication indicating the patient is enrolled, and resubmitting the non-enrollment transaction to proceed with the non-enrollment transaction. This encompasses interactions between users regarding a patient transaction based on being non-enrolled and enrolled in a program. Such manual steps encompass Certain Methods of Organizing Human Activity.
Claims 2-17 and 19 incorporate the abstract idea identified above and recite additional limitations that expand on the abstract idea. For example, claims 2-4 further expand on the patient identifying information and practice identifying information, which is part of the abstract idea identified above. Claims 5-10 further expand on indication non-enrollment transaction, which is part of the abstract idea identified above. Claim 11 further recites initiating enrollment and receiving enrollment information, which similarly encompasses managing interactions between people. Claims 12-15 further expands on transmitting enrollment requests to different entities, which similarly encompasses managing interactions between people. Claims 16, 17, and 19 further expands on transmitting enrollment and non-enrollment transactions to different services, which similarly encompasses managing interactions between people. As explained above, these manual steps encompass Certain Methods of Organizing Human Activity.
Step 2A Prong Two
This judicial exception is not integrated into a practical application because the remaining elements amount to no more than general purpose computer components programmed to perform the abstract ideas along with adding elements similar to adding the words “apply it” to the abstract idea, and generally linking the abstract idea to a particular technological environment, along with insignificant, extra-solution data gathering activity.
Claims 1-13, directly or indirectly, recite the following additional elements at a high level of generality and merely utilized as tools to implement the abstract idea:
Claims 1:
a processor; and a memory device including instructions, which when executed by the processor, cause the processor to perform operations.
Claim 20:
A non-transitory computer-readable medium including instructions for managing patients of a healthcare practice, which when executed by a computer, cause the computer to perform operations.
Claims 1, 18, 20:
implementing a partner software platform for managing patients, the partner software platform provided by a partner of the healthcare practice and including interfaces for enrollment and non-enrollment transactions regarding the patients.
presenting an interface for a non-enrollment transaction to a user of the healthcare practice system, the non-enrollment interface including user interface controls.
Implemented with a first microservice workflow by the server system.
Presenting an enrollment transaction interface…the enrollment transaction interface including user interface controls.
The written description discloses that the recited computer components encompass generic components including “Respective compute nodes may be embodied as a type of device, appliance, computer, or other "thing" capable of communicating with other devices, networking, or endpoint components. For example, a compute device may be embodied as a personal computer, server, smartphone, a mobile compute device, a smart appliance, an in- vehicle compute system (e.g., a navigation system), a self-contained device having an outer case, shell, etc., or other device or system capable of performing the described functions” (see paragraph 0124). As set forth in the MPEP 2106.04(d) “merely including instructions to implement an abstract idea on a computer” is an example of when an abstract idea has not been integrated into a practical application.
Claims 1-20, directly or indirectly, recite the following additional elements at a high level of generality, involving no more that extra-solution data gathering and transmitting activity:
Claims 1, 18, 20:
transmitting, via the interface for the non-enrollment transaction, an electronic indication…to a server system.
Receiving…electronic indication from the server system.
Transmitting, via the enrollment transaction interface…to the server system.
the partner software platform is configured with an event handler, the event handler configured to consume events spawned by the server system, and based on an event, the event handler is configured to retransmit the electronic indication…to the server system.
Claim 11:
populating a portion of a webpage with content for display at the healthcare practice system, wherein the portion of the webpage is used to prompt.
Claims 13-15:
the server system performs operations.
These additional elements are recited at a high degree of generality and are merely involved in insignificant extra solution data gathering and transmitting of data over a generic computer network. As set forth in MPEP 2106.05(g) insignificant, extra-solution activity, such as insignificant acquisition and data transmission, is an example of when an abstract idea has not been integrated into a practical application.
Claims 5-10, 16-17, and 19, recite the following additional elements at a high level of generality, generally linking the abstract idea to a particular technological environment:
Claims 5-10:
Hypertext Transfer Protocol (HTTP).
eXtended Markup Language (XML) Simple Object Access Protocol (SOAP).
Representational State Transfer (REST).
Claim 16-17, 19:
an application programming interface (API) exposed to the healthcare practice system, wherein the API exposes a number of services.
The different types of transmission protocols and implementing an API are recited at a high degree of generality and do not a technical improvement or an improvement to another technical field.
Step 2B
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to integration into a practical application, the additional elements are recited at a high level of generality, and the written description indicates that these elements are generic computer components. Using generic computer components to perform abstract ideas does not provide a necessary inventive concept. See Alice, 573 U.S. at 223 (“mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention.”).
Insignificant, extra solution, data gathering activity (e.g. transmitting and receiving data over a computer network) has been found to not amount to significantly more than an abstract idea (see MPEP 2106.05(g) and Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354-55, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016)).
Generally linking the abstract idea to a particular technological environment (e.g. communication protocols and API software) does not amount to significantly more than the abstract idea (see MPEP 2016.05(h) and Affinity Labs of Texas v. DirecTV, LLC, 838 F.3d 1253, 120 USPQ2d 1201 (Fed. Cir. 2016)).
Additionally, the aforementioned additional elements, considered in combination, do not provide an improvement to a technical field or provide a technical improvement to a technical problem. Therefore, whether considered alone or in combination, the additional elements do not amount to significantly more than the abstract idea.
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.
Claim(s) is/are rejected under 35 U.S.C. 103 as being unpatentable over Pinsonneault, US Patent No. 8,639,523 in view of Pinsonneau, US Patent No. 8,392,219 (hereinafter Pinnsonneau2) and further in view of Ozeran, US Patent Application Publication No. 2020/0335188.
As per claim 1, Pinsonneault teaches healthcare practice system used for managing patients of a healthcare practice, the healthcare practice system comprising: a processor; and a memory device including instructions, which when executed by the processor, cause the processor to perform operations (see column 1, lines 53-56; processor in communication with memory to execute computer-executable instructions) comprising: implementing a partner software platform for managing patients, the partner software platform provided by a partner of the healthcare practice and including interfaces for enrollment and non-enrollment transactions regarding the patients (see column 3, lines 48-59; various user systems operated by hardware and software for transmitting and receiving data); presenting an interface for a non-enrollment transaction to a user of the healthcare practice system, the non-enrollment interface including user interface controls to provide patient information of a patient for a non-enrollment transaction (see column 9, lines 58-62 and column 10, lines 23-27; user of the healthcare practice system being the pharmacy that creates a claim. A claim may be generated for a patient not enrolled in a prescription reward program (non-enrollment transaction)); transmitting, via the interface for the non-enrollment transaction, an electronic indication of the non-enrollment transaction to a server system (see column 9, lines 56-58; claim (non-enrollment transaction) is sent to enrollment module; column 9, lines 9-13; centralized switch, containing the enrollment module, functioning as a server system), and the non-enrollment transaction including patient identifying information, partner identifying information to identify the partner, practice identifying information to identify the healthcare practice, and a therapy identifier (see column 7, line 39 – column 8, line 21; claim (non-enrollment transaction) includes prescriber ID, pharmacy ID; patient name; prescribed drug ID); receiving a first responsive electronic indication from the server system indicating that the patient is not enrolled in a patient services program offered by the partner (see column 10, lines 43-27; sends back enrollment request indicating the patient is not enrolled); presenting an enrollment transaction interface to the user of the healthcare practice system, the enrollment transaction interface including user interface controls to provide patient enrollment information for an enrollment transaction (see column 10, lines 27-33; presented enrollment request requests an indicator of whether the patient desires to enroll in a prescription rewards program to be resubmit claim with enrollment indicator (enrollment transaction)); transmitting, via the enrollment transaction interface, the patient enrollment information to the server system (see column 10, lines 27-33; presented enrollment request requests an indicator of whether the patient desires to enroll in a prescription rewards program to be resubmit claim with enrollment indicator (enrollment transaction)); and resubmitting the non-enrollment transaction, wherein the partner software platform is configured with an event handler, the event handler configured to consume events spawned by the server system, and based on an event (see column 7, lines 20-36; switch, operating as a server, includes interfaces to various network connected devices and executes software and provides web portal access to transmit and receive prescription and claim (including enrollment) data, which his encompassed by the event handler configured to consume evens spawned by the server system), the event handler is configured to retransmit the electronic indication of the non-enrollment transaction to the server system to proceed with the non-enrollment transaction (see column 10, lines 31-33; transaction is resubmitted).
Pinsonneault does not explicitly teach the non-enrollment transaction being implemented with a first microservice workflow by the server system. Pinsonneault does not explicitly teach receiving a second responsive electronic indication from the server system indicating that the patient is enrolled.
Pinnsonneau2 teaches a similar enrollment validation process including receiving a second responsive electronic indication from the server system indicating that the patient is enrolled (see column 11, lines 50-59; provides a response in the form of an approval response). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to provide a patient enrollment response within the enrollment system of Pinsonneault with the motivation of further streamlining patient enrollment for healthcare programs (see column 1, lines 43-25 of Pinnsonneau2).
Ozeran teaches a process that includes patient enrollment transactions (see paragraph 0036) with a plurality of microservices for processing the patient data (see paragraph 0055). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to implement the transaction of Pinsonneault with a first microservice workflow as in Ozeran with the motivation of maximizing system adaptability to rapidly accommodate new data types (see paragraph 0166 of Ozeran).
As per claim 2, Pinsonneault, Pinsonneault2, and Ozeran teaches the system of claim 1 as described above. Pinsonneault further teaches the patient identifying information includes a first name of the patient, a last name of the patient, a date of birth of the patient, and a ZIP code of the patient (see column 12, lines 19-23).
As per claim 3, Pinsonneault, Pinsonneault2, and Ozeran teaches the system of claim 1 as described above. Pinsonneault further teaches patient identifying information includes an insurance member identification of the patient and an insurance identifier corresponding to the insurance member identification of the patient (see column 10, lines 3-6; patient information includes insurance coverage information).
As per claim 4, Pinsonneault, Pinsonneault2, and Ozeran teaches the system of claim 1 as described above. Pinsonneault further teaches the practice identifying information (see column 9, lines 64-67). Pinsonneault does not explicitly tech the identifying information includes a city of operation of the healthcare practice, a ZIP code of the healthcare practice, a national provider identifier (NPI) of the healthcare practice, and a tax identification of the healthcare practice. Pinsonneault2 further teaches identifying information includes a national provider identifier (NPI) of the healthcare practice (see column 7, line 60 – column 8, line 6). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to add additional identifying information such as a NPI with the motivation of better identifying the prescriber. Additionally, the content of the practice identifying information amounts non-functional descriptive material, which does not differentiate the claim from the prior art.
As per claim 11, Pinsonneault, Pinsonneault2, and Ozeran teaches the system of claim 1 as described above. Pinsonneault further teaches initiating enrollment and receiving enrollment information comprises populating a portion of a webpage with content for display at the healthcare practice system, wherein the portion of the webpage is used to prompt a user of the healthcare practice system for information used in enrollment (see column 6, line 67 – column 7, line 8; web portal used for data interactions between modules and switch, column 7, lines 37-43; switch displays prompts for information used in enrollment).
As per claim 12, Pinsonneault, Pinsonneault2, and Ozeran teaches the system of claim 1 as described above. Pinsonneault further teaches the server system performs operations comprising formatting and transmitting an enrollment request to a drug manufacturer to enroll in a patient services program associated with the drug manufacturer, the enrollment request specifically formatted for an enrollment process specific to the drug manufacturer (see column 6, lines 24-32; enrollment may be specific to a claim processor system of a drug manufacturer; column 8, lines 17-25; formatting of enrollment request through back-end analytics, editing, and messaging for enrolling patients).
As per claim 14, Pinsonneault, Pinsonneault2, and Ozeran teaches the system of claim 1 as described above. Pinsonneault further teaches the server system performs operations comprising formatting and transmitting an enrollment request to a treatment distributor to enroll in a patient services program associated with the treatment distributor (see column 6, lines 24-32; enrollment may be specific to a claim processor system of a vendor or business associates of healthcare service providers (treatment distributor); column 8, lines 17-25; formatting of enrollment request through back-end analytics, editing, and messaging for enrolling patients).
As per claim 15, Pinsonneault, Pinsonneault2, and Ozeran teaches the system of claim 1 as described above. Pinsonneault further teaches the server system performs operations comprising formatting and transmitting an enrollment request to a treatment distributor to enroll in a patient services program, the patient services program requiring a specifically formatted enrollment (see column 6, lines 24-32; enrollment may be specific to a claim processor system of a vendor or business associates of healthcare service providers (treatment distributor); column 8, lines 17-25; formatting of enrollment request through back-end analytics, editing, and messaging for enrolling patients. Note: requirements at a specific program do not further limit the recited actions of formatting and transmitting).
As per claim 16, Pinsonneault, Pinsonneault2, and Ozeran teaches the system of claim 1 as described above. Pinsonneault further teaches transmitting the non-enrollment transaction is performed through a number of services selected from: a benefits verification service, a prior authorization service, a copay service, a patient assistance program (PAP) service, and an enrollment service (see column 6, lines 24-32; benefits service, enrollment service as examples).
Pinsonneault does not explicitly teach an application programming interface (API) exposed to the healthcare practice system, wherein the API exposes one of a number of services. Ozeran further teaches a series of APIs exposed to a healthcare practice system and exposes a service (see paragraph 0252; API is used for services related to data validation). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to utilize API services for executing operations of Pinsonneault with the motivation of efficiently capturing and processing relevant treatment data and new types of data (see paragraph 0053 of Ozeran).
As per claim 17, Pinsonneault, Pinsonneault2, and Ozeran teaches the system of claim 1 as described above. Pinsonneault further teaches transmitting the patient enrollment information is performed through a number of services selected from: a benefits verification service, a prior authorization service, a copay service, a patient assistance program (PAP) service, and an enrollment service (see column 6, lines 24-32; benefits service, enrollment service as examples).
Pinsonneault does not explicitly teach an application programming interface (API) exposed to the healthcare practice system, wherein the API exposes a number of services. Ozeran further teaches a series of APIs exposed to a healthcare practice system and exposes a service (see paragraph 0252; API is used for services related to data validation). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to utilize API services for executing operations of Pinsonneault with the motivation of efficiently capturing and processing relevant treatment data and new types of data (see paragraph 0053 of Ozeran).
Claims 18-19 recite substantially similar method limitations to system claims 1 and 16 and, as such, are rejected for similar reasons as given above.
Claim 20 recites substantially similar computer medium limitations to system claim 1 and, as such, is rejected for similar reasons as given above.
Claim(s) is/are rejected under 35 U.S.C. 103 as being unpatentable over Pinsonneault, US Patent No. 8,639,523 in view of Pinsonneau, US Patent No. 8,392,219 (hereinafter Pinnsonneau2) and further in view of Ozeran, US Patent Application Publication No. 2020/0335188 and further in view of Mendell, US Patent Application Publication No. 2023/0196471.
As per claim 5, Pinsonneault, Pinsonneault2, and Ozeran teaches the system of claim 1 as described above. Pinsonneault further teaches the electronic indication of non- enrollment transaction is a request for benefits verification of a patient treatment (see column 10, lines 23-25; prescription transaction functions as a request for benefits verification (enrollment in program)). Pinsonneault does not explicitly teach the transaction is a Hypertext Transfer Protocol (HTTP) message. Mendell teaches sending messages related to prescription approval (see paragraph 0350) using a Hypertext Transfer Protocol (HTTP) message (see paragraph 0430). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to incorporate HTTP messaging in the system of Pinsonneault with the motivation of recognizing a variety of exemplary ways of communicating electronic data transfers (see paragraph 00430 of Mendell).
As per claim 6, Pinsonneault, Pinsonneault2, Ozeran, and Mendell teaches the system of claim 5 as described above. Pinsonneault does not explicitly teach the Hypertext Transfer Protocol (HTTP) message request is an eXtended Markup Language (XML) Simple Object Access Protocol (SOAP) message. Mendell further teaches the Hypertext Transfer Protocol (HTTP) message request is an eXtended Markup Language (XML) Simple Object Access Protocol (SOAP) message (see paragraph 0430). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to incorporate XML, SOAP messaging in the system of Pinsonneault with the motivation of recognizing a variety of exemplary ways of communicating electronic data transfers (see paragraph 00430 of Mendell).
As per claim 7, Pinsonneault, Pinsonneault2, Ozeran, and Mendell teaches the system of claim 5 as described above. Pinsonneault does not explicitly teach the Hypertext Transfer Protocol (HTTP) message request is a Representational State Transfer (REST) message. Mendell further teaches the Hypertext Transfer Protocol (HTTP) message request is a Representational State Transfer (REST) message (see paragraph 0430). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to incorporate REST messaging in the system of Pinsonneault with the motivation of recognizing a variety of exemplary ways of communicating electronic data transfers (see paragraph 00430 of Mendell).
As per claim 8, Pinsonneault, Pinsonneault2, Ozeran teaches the system of claim 1 as described above. Mills does not explicitly teach the electronic indication of non-enrollment transaction is a Hypertext Transfer Protocol (HTTP) message request for prior authorization of a patient treatment. Mendell teaches an electronic indication is a Hypertext Transfer Protocol (HTTP) message request for prior authorization of a patient treatment (see paragraph 0350; prior authorization; paragraph 0430; HTTP message). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to incorporate HTTP messaging in the system of Pinsonneault with the motivation of recognizing a variety of exemplary ways of communicating electronic data transfers (see paragraph 00430 of Mendell).
As per claim 9, Pinsonneault, Pinsonneault2, Ozeran teaches the system of claim 1 as described above. Mills does not explicitly teach the electronic indication of non-enrollment transaction is a Hypertext Transfer Protocol (HTTP) message request for a copay status. Mendell teaches an electronic indication is a Hypertext Transfer Protocol (HTTP) message request for a copay status (see paragraph 0258; copay status; paragraph 0430; HTTP message). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to incorporate HTTP messaging in the system of Pinsonneault with the motivation of recognizing a variety of exemplary ways of communicating electronic data transfers (see paragraph 00430 of Mendell).
As per claim 10, Pinsonneault, Pinsonneault2, Ozeran teaches the system of claim 1 as described above. Mills does not explicitly teach the electronic indication of non-enrollment transaction is a Hypertext Transfer Protocol (HTTP) message request for a patient assistance program. Mendell teaches an electronic transaction is a Hypertext Transfer Protocol (HTTP) message request for a patient assistance program (see paragraph 0066; patient can enroll in a loyalty or reward program, representing a patient assistance program; paragraph 0430; HTTP message). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to incorporate HTTP messaging in the system of Pinsonneault with the motivation of recognizing a variety of exemplary ways of communicating electronic data transfers (see paragraph 00430 of Mendell).
Claim(s) is/are rejected under 35 U.S.C. 103 as being unpatentable over Pinsonneault, US Patent No. 8,639,523 in view of Pinsonneau, US Patent No. 8,392,219 (hereinafter Pinnsonneau2) and further in view of Ozeran, US Patent Application Publication No. 2020/0335188 and further in view of Avery, US Patent Application Publication No. 2020/002042.
As per claim 13, Pinsonneault, Pinsonneault2, and Ozeran teaches the system of claim 1 as described above. Pinsonneault further teaches the server system performs operations comprising formatting and transmitting an enrollment request to enroll in a patient services program (see column 6, lines 24-32; enrollment may be specific to a claim processor system of a drug manufacturer; column 8, lines 17-25; formatting of enrollment request through back-end analytics, editing, and messaging for enrolling patients). Pinsonneault does not explicitly teach enrolling with a device manufacturer. Avery teaches enrolling a patient with a device manufacturer (see paragraphs 0007 and 0064; patient data may be enrolled for monitoring devices from different manufacturers). It would have been obvious to one of ordinary skill in the art at the time of the effective filing date to enroll with device manufacturers for a patient in Pinsonneault with the motivation of correctly enrolling data in a HIPPA compliant manner (see paragraph 0079 of Avery).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Oliver, International Publication no. WO 2021/096538 A1, discloses a microservices architecture capable of enrolling patients in individual services.
Dana, US Patent Application Publication No. 2021/0151155, discloses patient enrollment in a drug distribution program, with an enrollment process and enrollment validation.
Lawrence, US Patent No. 10,496,793, discloses a patient enrollment process for a prescription program.
Baumgartner et al., A Novel Digital Pill System for Medication Adherence Measurement and Reporting: Usability Validation Study, discloses a patient enrollment process.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to C. Luke Gilligan whose telephone number is (571)272-6770. The examiner can normally be reached Monday through Friday 9:00 - 5:00.
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, Robert Morgan can be reached at 571-272-6773. 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.
C. Luke Gilligan
Primary Examiner
Art Unit 3683
/CHRISTOPHER L GILLIGAN/ Primary Examiner, Art Unit 3683