Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439).
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 .
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 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.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Information Disclosure Statement
Munoz et al. (U.S. PG PUB 2017/0168555) is from Applicants IDS submitted on 3/22/23.
Priority
A certified English translation of the foreign application was submitted on 11/13/2025. Therefore, effective filing date of application is 11/25/2019.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a first and second system, each which is configured to” in claims 1, 14, and 20.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 7, 8, 10-14, 17, and 19-28 are rejected under 35 U.S.C. 103 as being unpatentable over Munoz et al. (U.S. PG PUB 2017/0168555).
Regarding claim 1, Munoz teaches a method for controlling a wearable device (see ¶ [0020] “a personal training computer (TC)”), wherein the wearable device comprises a first system and a second system (see Fig. 5, 500 and 530), each of which is configured to run on the wearable device as an operating system (see ¶[0059], [0068]-[0069]), power consumption of the first system is higher than that of the second system (see ¶ [0077] “In one embodiment, the device 100 comprises a low power control unit (e.g. the MCU 530) for running at least the PAA 220 during the limited operation mode 212, and a high power control unit (e.g. the MPU 500) for running the operating system 300 during the normal operation mode 210. As indicated above, the low power control unit 530 has lower power consumption in performing a given task than the high power control unit 500.”), and the method comprises:
when an operating system running on the wearable device is the first system, acquiring start time of a schedule (see ¶[0104] “This may be the case when the user 110 is starting the physical activity session according to predetermined training program” and [0105] “training program” and [0025] “training schedule”);
acquiring, by the wearable device, user behavior data on condition of reaching the start time (see ¶ [0020] “As shown in FIG. 1, it is common to wear a personal training computer (TC) 100 during an exercise. The training computer 100 may be a wrist worn device, such as a smart watch. From the training computer 100, the exerciser 110 may monitor training parameters that characterize the physiological state during the exercise in real time. The physiological state may be detected from one or more performance metrics, such as by monitoring how the heart rate changes as the training session goes on.” See ¶ [0099] “This way, the device 100 may detect, on the basis of the detected sensors, which type of exercise is being performed or is going to be performed. It may also be that certain type of sport, such as jogging, typically lasts for 45 minutes with this user 110. Therefore, it may be expected that the exercise will also now last for the same duration” See ¶ [0104] “In an embodiment, the user 110 inputs an indication of the duration of the physical activity session before starting the exercise. This may be the case when the user 110 is starting the physical activity session according to predetermined training program”); and
switching the operating system running on the wearable device to the second system (see ¶[0092] “physical activity session (e.g. of the exercise) and decide to switch to the limited operation mode” and [0078] “In such case, the switch to the limited operation mode 212 in step 204 may comprise activating the low power control unit 530 to run at least the PAA 220 and inactivating the high power control unit 500. In an embodiment, inactivating the MPU 500 may comprise inactivating the DDR memory accessible by the MPU 500. Thus, power consumption rate of the device 100 may be reduced. This mode may be referred as “MCU on-mode” 212A, as shown in FIG. 2C.”) in the condition that the user behavior data meets a system switching condition (see [0099]-[0101]);
wherein the method further comprises:
acquiring a component identifier selected in the first system, wherein the component identifier is a mapping of a component on the first system (see ¶ [0095] “The detection of the sensors may be based on identifiers transmitted by the sensors via BLT, for example. From the identifiers, the device 100 may detect that the surrounding devices are physical activity sensors.”);
sending the component identifier to a second processor corresponding to the second system through a serial peripheral interface (see ¶[0072] “For example, the connections may be based on an inter-integrated circuit (I2C) bus, integrated interchip sound (I2S) bus, a serial peripheral interface (SPI) bus.”); and
configuring a component corresponding to the component identifier by the second processor (see Table 2, in ¶ [0146] which shows the identifier, i.e. name of sensor, for example, GPS, which is configured, for example, enabled to use in selected limited way).
Because Munoz discloses multiple embodiments and implementations, and all the findings may be disclosed in different embodiments/implementations, obviousness rejection is made. One of ordinary skill in the art at the time of the invention would be able to combine different embodiments adjacent to each other in the prior art and does not require a leap of inventiveness. Munoz discloses that these embodiments/implementations are used in order to optimize power consumption of the device while providing all needed functionalities (see ¶ [0028] of Munoz).
Regarding claim 7, Munoz teaches wherein the acquiring user behavior data comprises: acquiring a heart rate value and a credibility corresponding to the heart rate value; and wherein the switching an operating system running on the wearable device to the second system in the condition that the user behavior data meets a system switching condition comprises: switching the operating system running on the wearable device to the second system in the condition that the credibility reaches a preset credibility threshold and the heart rate value meets a heart rate threshold condition (see ¶[0100] “In one embodiment shown in FIG. 10, the device 100 may in step 1000 determine at least one property of the ongoing physical activity session. The property may be, e.g., heart activity related property, such as average heart rate or heart rate variation, or an accumulated property, such as distance elapsed, calories consumed or steps taken.” See ¶[0117] “In an embodiment, the physical activity algorithm causes determination of minimum and maximum values for a certain physical activity measure. Such measure may be, e.g. heart rate, altitude (e.g. above a sea level), speed, to mention only a few non-limiting examples.” See ¶[0028] “In order to optimize the power consumption of the device while providing all needed functionalities 104 to the user 110 of the device 100, the device 100 may in step 204 switch between the normal operation mode 210 and the limited operation mode 212. The power consumption of the device 100 during the limited (operation) mode 212 may be smaller for a given task than during the normal (operation) mode 210. Thus, the limited operation mode 212 may be used when smaller power consumption is needed and a smaller amount of available functionalities 104 is enough, whereas the normal operation mode 210 may be applied when larger set of functionalities 104 is needed.”).
Regarding claim 8, Munoz teaches wherein the switching the operating system running on the wearable device to the second system comprises: controlling a switch in the wearable device to switch from a path between a first processor corresponding to the first system and other elements to a path between a second processor corresponding to the second system and other elements (see ¶[0028] “In order to optimize the power consumption of the device while providing all needed functionalities 104 to the user 110 of the device 100, the device 100 may in step 204 switch between the normal operation mode 210 and the limited operation mode 212. The power consumption of the device 100 during the limited (operation) mode 212 may be smaller for a given task than during the normal (operation) mode 210. Thus, the limited operation mode 212 may be used when smaller power consumption is needed and a smaller amount of available functionalities 104 is enough, whereas the normal operation mode 210 may be applied when larger set of functionalities 104 is needed.”).
Regarding claim 10, Munoz teaches further comprising: acquiring end time of the schedule; and switching the operating system running on the wearable device from the second system to the first system in the condition of reaching the end time (see ¶[0107] “In an embodiment, once the limited operation mode 212 is switched on, the limited mode 212 is maintained on until a predetermined duration is expired, after which the normal mode 210 is automatically triggered on. Thus, the limited operation mode 212 may be kept on for some time even after the physical activity session is over.”).
Regarding claim 11, Munoz teaches wherein the switching an operating system running on the wearable device to the second system in the condition that the user behavior data meets a system switching condition comprises: still keeping the operating system running on the wearable device being the second system in the condition that the operating system running on the wearable device is the second system and the system switching condition is met (see ¶[0090] “On the other hand, if the comparison result indicates that the remaining power resources are above the predetermined battery threshold and/or the power consumption rate is below the predetermined consumption threshold, then the MPU 500 may decide to maintain the normal operation mode 210.”).
Regarding claim 12, Munoz teaches wherein the acquiring start time of a schedule comprises: acquiring, by the wearable device, the start time of the schedule in the condition that the operating system running on the wearable device is the first system; wherein the start time of the schedule is configured on the first system (see ¶[0104] “In an embodiment, the user 110 inputs an indication of the duration of the physical activity session before starting the exercise. This may be the case when the user 110 is starting the physical activity session according to predetermined training program. The user 110 may design the training programs with the device 100 or in the web service 120, or in a separate mobile phone, and upload the designed program(s) to the device 100. As such, the duration of the exercise may be known right at the start of the exercise.’).
Regarding claim 13, Munoz teaches wherein the switching an operating system running on the wearable device to the second system in the condition that the user behavior data meets a system switching condition comprises: turning off the first system and switch the running system from the first system to the second system in the condition that the user behavior data meets the system switching condition (see ¶ [0136] “In an embodiment, the functionalities not available in the limited operation mode 212 include a touch sensitivity of the display 102 of the device 100. This may be beneficial as, though the touch sensitive display 102 is user friendly, such display causes high power consumption even though it may not be typically used during the exercise. Therefore, in order to save the power, the touch sensitivity may be switched off with the touch controller 510 upon entering the limited operation mode 212. It may be noted also tis some embodiments, the display 102 may be driven with the MCU 530 in the limited operation mode 212, as shown in FIG. 5. The MCU 530 may not have access to the touch controller 510.”).
Regarding claim 14, is a device claim corresponding to method claim 1, and is rejected for the same reasons. In addition, Munoz teaches an electronic device comprising a memory and processor, wherein the electronic device is configured to server as a wearable device (see ¶ [0168] and ¶ [0020]).
Regarding claims 17 and 19 correspond with method claims 7 and 10 respectively, and are rejected for the same reasons indicated above.
Regarding claim 20, is a medium claim corresponding to method claim 1, and is rejected for the same reasons. In addition, Munoz teaches a non-transitory computer readable storage medium storing a computer program, wherein the non-transitory medium is applicable to a wearable device (see ¶ [0168] and ¶ [0020]).
Regarding claim 21, Munoz teaches wherein the switching an operating system running on the wearable device to the second system in the condition that the user behavior data meets a system switching condition comprises: determining a schedule category according to the user behavior data (see ¶ [0104] “In an embodiment, the user 110 inputs an indication of the duration of the physical activity session before starting the exercise. This may be the case when the user 110 is starting the physical activity session according to predetermined training program. The user 110 may design the training programs with the device 100 or in the web service 120, or in a separate mobile phone, and upload the designed program(s) to the device 100. As such, the duration of the exercise may be known right at the start of the exercise.”); and switching the operating system running on the wearable device to the second system in the condition that the schedule category is a category meets the system switching condition (see ¶[0162] “In an embodiment, this decision may result in a switch between the limited operation mode 212 and the normal operation mode 210, limiting the availability of certain features or limiting the performance of certain features (see Table 2). When making the decision, the device 100 may be operating either in the limited operation mode 212 or in the normal operation mode 210.”).
Regarding claim 22, Munoz teaches further comprising: acquiring a configured schedule category corresponding to the schedule; wherein the switching an operating system running on the wearable device to the second system in the condition that the user behavior data meets a system switching condition comprises: switching an operating system running on the wearable device to the second system in the condition that the user behavior data meets a system switching condition corresponding to the schedule category (see ¶[0162] “In an embodiment, this decision may result in a switch between the limited operation mode 212 and the normal operation mode 210, limiting the availability of certain features or limiting the performance of certain features (see Table 2). When making the decision, the device 100 may be operating either in the limited operation mode 212 or in the normal operation mode 210.” And ¶ [0108] “However, in an embodiment, as illustrated in FIGS. 7 and 8, the device 100 may detect that the physical activity session is ended. This detection may be automatic or inputted by the user 110 As a consequence, in step 702, the device 100 may enter to the normal operation mode 210. This may comprise activating all layers of the operating system 300, thereby allowing the larger set of functionalities to be run on the device 100. At the same time, however, the DDR memories may need to be activated and, thus, the power consumption may increase.”).
Regarding claim 23, Munoz teaches wherein the switching an operating system running on the wearable device to the second system in the condition that the user behavior data meets a system switching condition corresponding to the schedule category comprises: switching the operating system running on the wearable device to the second system in the condition that the user behavior data comprises a heart rate value and the heart rate value meeting a heart rate threshold condition corresponding to a schedule category (see ¶ [0129] “In an embodiment, the functionalities 104 available in the limited operation mode 212 include audio guidance so that the user 110 may hear, e.g., when the heart rate exceeds a certain level.”); or switching the operating system running on the wearable device to the second system in the condition that the user behavior data comprises an acceleration value and the acceleration value meeting an acceleration threshold condition corresponding to a schedule category; or switching the operating system running on the wearable device to the second system in the condition that the user behavior data comprises a heart rate value and an acceleration value, the heart rate value meeting a heart rate threshold condition corresponding to a schedule category, and the acceleration value meeting an acceleration threshold condition corresponding to the schedule category.
Regarding claim 24, Munoz teaches further comprising: determining that the user behavior data comprises at least one of an acceleration value and a heart rate value in the condition that the schedule category is an exercise category (see ¶ [0067] “As an alternative or in addition to, the heart activity detection may take place electrically in which case the device 100 may receive heart activity data may be received via one of the RF connection interfaces 518 from the electrical heart activity sensor. In an embodiment, the physical activity sensors 114 comprise an accelerometer for determining motion of the device 100. The accelerometer may be a three-dimensional accelerometer capable of detecting motion in each direction of a three dimensional coordinate system.”).
Regarding claim 25, Munoz teaches further comprising: determining that the user behavior data comprises a heart rate value, or comprises both a heart rate value and an acceleration value in the condition that the schedule category is a sleep category or a conference category (see ¶ [0087] “In an embodiment, the physical activity session is any session during which physical activity may be measured. For example, sleeping may be a physical activity which may be measured in terms of activity measurement during the sleep. In an embodiment, however, the physical activity session is an exercise performed by the person 110. The exercise may be differentiated from other physical activity sessions (such as from sleeping) by defining an activity threshold (e.g. in terms of calories consumed per given time unit) which divides physical activities into exercises and non-exercises.”).
Regarding claim 26, Munoz teaches wherein the acquiring a component identifier selected in the first system comprises: acquiring corresponding component identifier within a schedule start time and a schedule end time of the schedule configured in the first system (see ¶ [0086] “There may be a predetermined time duration which divides a physical activity session into a short physical activity session and a (long) physical activity session.”);
and the configuring a component corresponding to the component identifier by the second processor comprises: configuring the component corresponding to the component identifier within the schedule start time and the schedule end time by the second processor (see ¶ [0104] “In an embodiment, the user 110 inputs an indication of the duration of the physical activity session before starting the exercise. This may be the case when the user 110 is starting the physical activity session according to predetermined training program. The user 110 may design the training programs with the device 100 or in the web service 120, or in a separate mobile phone, and upload the designed program(s) to the device 100. As such, the duration of the exercise may be known right at the start of the exercise.” See ¶[0141] “These features of the exercise mode may affect the battery 506 life-time and therefore restrict the time duration that the device 100 may operate in such exercise mode (i.e. in the limited operation mode 212).”).
Regarding claim 27-28, correspond with method claims 21 and 22 respectively, and are rejected for the same reasons indicated above.
Response to Arguments
Applicant's arguments filed 3/23/2026 have been fully considered but they are not persuasive.
Regarding 101 rejections have been withdrawn, thus arguments are moot.
Regarding 103 rejections, applicants argue Munoz does not disclose identifiers transmitted through a serial peripheral interface and states that Munoz teaches it being transmitted via BLT, and further argues that Munoz does not disclose c. Applicant also argues there is no motivation to combine the different embodiments because they have different technical purpose.
Examiner disagrees. Munoz discloses the connections are not limited to BLT, but rather a number of different connections can be made, for example, see ¶[0072] “For example, the connections may be based on an inter-integrated circuit (I2C) bus, integrated interchip sound (I2S) bus, a serial peripheral interface (SPI) bus.” In addition, Munoz discloses in Table 2 in ¶ [0146] which shows the identifier, i.e. name of sensor, for example, GPS, which is configured, for example, enabled to use in selected limited way. Thus, Munoz discloses a component corresponding to the component identifier by the second processor. Furthermore, Munoz states that discloses embodiments may be combined and may be implemented in various ways (see ¶[0167] to ¶[0169]). Thus, one of ordinary skill in the art at the time of the invention would be able to combine different embodiments adjacent to each other in the prior art and does not require a leap of inventiveness. Munoz discloses that these embodiments/implementations are used in order to optimize power consumption of the device while providing all needed functionalities (see ¶ [0028] of Munoz).
Support for Amendments and Newly Added Claims
Applicants are respectfully requested, in the event of an amendment to claims or submission of new claims, that such claims and their limitations be directly mapped to the specification, which provides support for the subject matter. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121(b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.121(b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as “Applicants believe no new matter has been introduced” may be deemed insufficient.
Interview Requests
In accordance with 37 CFR 1.133(a)(3), requests for interview must be made in advance. Interview requests are to be made by telephone (571-270-7848) call or email (carina.yun@uspto.gov). Applicants must provide a detailed agenda as to what will be discussed (generic statement such as “discuss §102 rejection” or “discuss rejections of claims 1-3” may be denied interview). The detail agenda along with any proposed amendments is to be written on a PTOL-413A or a custom form and should be emailed, (subject to MPEP 713.01.I / MPEP 502.03) to the Examiner prior to requesting for interview. Interview requests submitted within amendments may be denied because the Examiner was not notified, in advance, of the Applicant Initiated Interview Request and due to time constraints may not be able to review the interview request to prior to the mailing of the next Office Action.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Remis et al. (U.S. PG PUB 2018/0088958) teaches managing peripheral devices using a data protocol is disclosed. A connection module determines one or more communication bus cables that communicatively couple one or more peripheral devices to an information handling device. A data module reads a data packet associated with a peripheral device over each of the one or more communication bus cables. Each data packet includes an identifier for a location where the peripheral device is installed. A topology module determines a cable connection configuration for the one or more communication bus cables and the one or more peripheral devices based on the installation location identifier received from each of the data packets associated with the one or more peripheral devices.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARINA YUN whose telephone number is (571)270-7848. The examiner can normally be reached Mon, Tues, Thurs, 9-4 (EST).
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 call.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached on (571) 270-3180. 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.
Carina Yun
Patent Examiner
Art Unit 2194
/CARINA YUN/Examiner, Art Unit 2194
Prosecution Insights