DETAILED ACTION
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 .
Drawings
Regarding FIG. 1, there is a lack of agreement between the drawing and the specification as originally filed in regards to reference character 132. In other words, the specification as originally filed clearly describes reference character 132 as “physical therapist computing device 132,” throughout. However, FIG. 1 clearly labels reference character 132 as “patient computing device.” Therefore, the meaning is unclear. Appropriate correction is required by amending reference character 132 as “physical therapist computing device 132,” to overcome the FIG.1 drawing objection
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1 – “Statutory Category Identification”
Claim 1 is directed to “a non-transitory machine readable storage medium” (i.e. a machine), claim 8 is directed to “an apparatus” (i.e. a machine), and claim 15 is directed to “a method” (i.e. a process), hence the claims are directed to one of the four statutory categories (i.e. process, machine, manufacture, or composition of matter). In other words, Step 1 of the subject-matter eligibility analysis is “Yes.”
Step 2A, Prong 1 “Abstract Idea Identification”
However, the claims are drawn to the abstract idea of “generating an exercise profile,” in the form of “certain methods of organizing human activity,” in terms of managing personal behavior or relationships or interactions between people (including social activities, teaching and following rules or instructions), or reasonably in the form of “mental processes,” in terms of processes that can be performed in the human mind (including an observation, evaluation, judgement or opinion). Regardless, the claims are reasonably understood as either “certain methods of organizing human activity” or “mental processes,” which require the following limitations:
Per claim 1:
“obtain an indication of a characteristic for an exercise;
obtain a video depicting a person performing the exercise;
analyze the video to detect a body position and a movement of the person performing the exercise; and
cause an exercise profile to be stored for the exercise, the exercise profile including the indication of the characteristic for the exercise, an identification of the body position, and an identification of the movement.”
Per claim 8:
“obtain an indication of a characteristic for an exercise;
Obtain a video depicting a person performing the exercise;
Analyze the video to detect a body position and a movement of the person performing the exercise; and
cause an exercise profile to be stored for the exercise, the exercise profile including the indication of the characteristic for the exercise, an identification of the body position, and an identification of the movement.”
Per claim 15:
“obtaining an indication of a characteristic for an exercise;
obtaining a video depicting a person performing the exercise;
analyzing the video to detect a body position and a movement of the person performing the exercise; and
causing an exercise profile to be stored for the exercise, the exercise profile including the indication of the characteristic for the exercise, an identification of the body position, and an identification of the movement.”
These limitations simply describe a process of data gathering and manipulation, which is partially analogous to “collecting information, analyzing it, and displaying certain results of the collection analysis” (i.e. Electric Power Group, LLC, v. Alstom, 830 F.3d 1350, 119 U.S.P.Q.2d 1739 (Fed. Cir. 2016)). Hence, these limitations are akin to an abstract idea which has been identified among non-limiting examples to be an abstract idea. In other words, Step 2A, Prong 1 of the subject-matter eligibility analysis is “Yes.”
Step 2A, Prong 2 – “Practical Application”
Furthermore, the claims do not include additional elements that either alone or in combination are sufficient to claim a practical application because to the extent that, e.g., “a user interface,” and “a machine learning algorithm,” are claimed, as these are merely claimed to generally link the use of a judicial exception to a particular technological environment or field of use. In other words, the claimed “generating an exercise profile,” is not providing a practical application, thus Step 2A, Prong 2 of the subject-matter eligibility analysis is “No.”
Step 2B – “Significantly More”
Likewise, the claims do not include additional elements that either alone or in combination are sufficient to amount to significantly more than the judicial exception because to the extent that, e.g. “a user interface,” and “a machine learning algorithm,” are claimed, these are generic, well-known, and conventional elements. As evidence that these are generic, well-known, and conventional elements (or an equivalent term), as a commercially available product, or in a manner that indicates that the additional elements are sufficiently well-known, the Applicant’s specification discloses these in a manner that indicates that the additional elements are sufficiently well-known that the specification does not need to describe the particulars of such additional elements to satisfy 35 U.S.C. § 112(a), per MPEP § 2106.07(a) III (a). As such, this satisfies the Examiner’s evidentiary burden requirement per the Berkheimer memo.
Moreover, the element of “a user interface,” is best described in paras. [0018], [0032] and [0033] as follows:
“[0018] The example user interface 104 provides one or more user interfaces for a physical therapist to interact with the exercise profiling device 102. For example, the user interface 104 may provide a webpage user interface that is accessible by the physical therapist computing device 132. Alternatively, any other type of user interface may be provided. Example user interfaces are illustrated in FIGS. 5 and 6.”
“[0032] The physical therapist computing device 132 is a personal computer. Alternatively, the physical therapist computing device 132 may be any type(s) of computing devices such as a mobile computing device, a desk computer, a laptop computer, etc. While the example system 100 includes a physical therapist computing device 132 that is separate from the exercise profiling device 102, in some implementations that components of the exercise profiling device 102 may be implemented on the physical therapist computing device 132.”
“[0033] The patient computing device 142 is a personal computer. Alternatively, the patient computing device 142 may be any type(s) of computing devices such as a mobile computing device, a desk computer, a laptop computer, etc. While the example system 100 includes a physical therapist computing device 132 that is separate from the patient computing device 142, in some implementations a single computer may implement the physical therapist computing device 132 and the patient computing device 142 (e.g. where a computing device located in a physical therapist's office it utilized for working to generate new exercise profiles and is utilized by clients when monitoring exercises).”
Due to the list of examples, this element is reasonably interpreted as a generic, well-known, and as a commercially available product which provides no details of anything beyond ubiquitous standard off-the-shelf equipment.
Likewise, the element of “a machine learning algorithm,” is best described in paras. [0103]-[0122] as follows: “using a machine learning algorithm.”
Due to the list of “using” examples (i.e. 1-20) this element is reasonably interpreted as a generic, well-known, and conventional element which provides no details of anything beyond ubiquitous machine learning software. Therefore, the Applicant’s own specification discloses ubiquitous standard equipment that is (1) generic, routine, conventional, and/or commercially available; and (2) does not provide anything significantly more. Thus, Step 2B, of the subject-matter eligibility analysis is “No.”
In addition, dependent claims 2-7, 9-14 and 16-20 do not provide a practical application and are insufficient to amount to significantly more than the judicial exception. As such, dependent claims 2-7, 9-14 and 16-20 are also rejected under 35 U.S.C. § 101, based on their respective dependencies to claim 1, 8 or 15. Therefore, claims 1-20 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by King, et al., (hereinafter referred to as “King,” US 2017/0259121).
Regarding claim 1, and substantially similar limitations in claims 8 and 15, King discloses obtain, via a user interface, an indication of a characteristic for an exercise; obtain, via the user interface, a video depicting a person performing the exercise (see para. [0061] Sensors 104 may be configured to generate output signals conveying information related to the user. In some embodiments, sensors 104 may include audiovisual sensors, activity sensors, physiological sensors, biometric sensors, or other sensors. Examples of such sensors may include a heart rate sensor, a blood pressure sensor/monitor, a weight scale, motion sensors, an optical sensor, biometric sensors, a video sensor, an audio sensor, a color sensor, a blood glucose monitor, a blood oxygen saturation monitor (e.g., a pulse oximeter), a hydration monitor, a skin/body temperature thermometer, a respiration monitor, electroencephalogram (EEG) electrodes, accelerometers, activity sensors/trackers, a GPS sensor, or other sensors. These examples should not be considered limiting. Sensors 104 are configured to generate various output signals conveying information related to the user that allows computing environment 100 to function as described herein. In some embodiments, sensors 104 may be disposed in a plurality of locations within or outside of computing environment 100. For example, sensors 104 may be on the user (e.g., wearable device), coupled with the client computing platforms 102, located in a medical device used by the user, positioned to point at the user (e.g., a video camera), or in other locations within or outside of computing environment 100. In some embodiments, information related to the user may be obtained through a combination of user input, user selection, sensor outputs, or other methods.
See para. [0062]: Information related to the user obtained from sensors 104 may include physiological information, behavior information, or other information obtained from sensors 104. Examples of physiological information may include heart rate, blood pressure, weight, pulse rate, blood chemistry, blood oxygen saturation, blood glucose level, hydration information, respiration rate, breathing information, skin/body temperature, brain activity, physical movement or lack of movement, activity duration information, physical pain information, or other physiological information. Examples of behavior information may include the user demeanor, voice, look, gestures, manners, attitude, or other behavior information. In some embodiments, user profile information may be updated based on information from sensors 104. For example, user profile information may be updated periodically, for example, user profile component 124 may be configured to periodically obtain information from sensors 104 and update the user profile information based on information from sensors 104. In some cases, the user may set the frequency of the update from the sensors. In some embodiments, the user profile information may be updated dynamically responsive to changes in information obtained from the sensors.
See para. [0091] In some embodiments, feedback may be obtained from a native application executing on the client computing devices to present videos, buffer videos, and communicate with servers 108 to effectuate workouts. In some cases, the application includes a user interface in which the video is displayed. In some embodiments, the user interface includes a plurality of inputs that, when selected by a user, cause messages indicative of a user input to be sent back to the servers 108 (or execute corresponding routines client side). In some embodiments, the inputs are regions of a screen overlaid on a video display, like touch-sensitive regions of a screen or clickable regions of a screen mapped to a corresponding event handler that is called upon a user input in the respective region. In some cases, the corresponding event handler may cause the client-side application to send a message back to the servers 108 indicative of the input);
analyze, using a machine learning algorithm, the video to detect a body position and a movement of the person performing the exercise
(see para. [0119] In some embodiments, some or all of the weights or coefficients described herein may be calculated by executing a machine learning algorithm on a training set of historical tagged data,); and
cause an exercise profile to be stored for the exercise, the exercise profile including the indication of the characteristic for the exercise, an identification of the body position, and an identification of the movement
See para. [0084] In some embodiments, feedback component 150 may be configured to receive feedback from sensors 104. For example, feedback may be in the form of physiological, behavior, medical, or other information received from sensors 104. Examples of feedback received from sensors 104 may include heart rate, pulse rate, blood oxygen saturation, respiration rate, breathing information, physical movement or lack of movement, body position duration of movement, physical pain information, or other physiological information. Examples of behavior information may include the user demeanor, voice, look, gestures, manners, attitude, or other behavior information. For example, a feedback received from sensors 104 may indicate that the user is following the direction correctly based on his movement, body position, breathing, etc. Or, the feedback may indicate that the user is not following correctly (e.g., fall detection, or the user is breathing heavily, heart rate is too high, etc.).
See para. [0119] The resulting, trained model, e.g., a vector of weights or thresholds, may be stored in memory and later retrieved for application to new calculations on newly calculated aggregate estimates).
Regarding claim 2, and substantially similar limitations in claims 9 and 16, King discloses wherein the characteristic is a body position of the person depicted in the video
(see para. [0054] In some embodiments, the dimensions of the matrix and other attributes of video blocks may define a parameter space, with each dimension of the matrix (or video block (or corresponding exercise) attribute) corresponding to a dimension in the parameter space. In some cases, the dimensions may be nominal, for example, identifying body parts engaged in videos located at positions along those dimensions corresponding to the body parts, or in some cases, the dimensions may be ordinal, for example indicating easier or more difficult versions of a given exercise, with a given instructor. Other examples of nominal dimensions include identities of instructors, gender of instructors, instances of workout equipment used in the respective videos, and the like.
see para. [0084] In some embodiments, feedback component 150 may be configured to receive feedback from sensors 104. For example, feedback may be in the form of physiological, behavior, medical, or other information received from sensors 104. Examples of feedback received from sensors 104 may include heart rate, pulse rate, blood oxygen saturation, respiration rate, breathing information, physical movement or lack of movement, body position duration of movement, physical pain information, or other physiological information. Examples of behavior information may include the user demeanor, voice, look, gestures, manners, attitude, or other behavior information. For example, a feedback received from sensors 104 may indicate that the user is following the direction correctly based on his movement, body position, breathing, etc. Or, the feedback may indicate that the user is not following correctly (e.g., fall detection, or the user is breathing heavily, heart rate is too high, etc.).
Regarding claim 3, and substantially similar limitations in claims 10 and 17, King discloses wherein the instructions, when executed, cause the programmable circuitry to present the exercise to a user (see para. [0027] In some embodiments, the selection of video blocks in a sequence is based on both a workout stream, the location of the user in the workout stream, and real-time feedback. For instance, a workout stream may specify a low-intensity warmup, a high-intensity warmup, legs, chest, back, arms, cardio, legs, chest, back, arms, cardio, legs, chest, back, arms, cardio, and a low-intensity cool down. Within each of these stages, each of which may correspond to a selection for a video block, some embodiments may select a video block consistent with the stage based on real-time feedback. For instance, after arms, the user may indicate they are overly tired via a native application, or a heart-rate monitor may indicate a heart rate above a threshold. In response, for the next stage, cardio, some embodiments may select a lower level of intensity than would have otherwise been choses, dynamically selecting a video block while staying within the confines of the stream to have a consistent workout sequence that is tailored to their experience. Variants are described below in which a gradient descent is used to train a model for selecting subsequent video blocks, workouts, or workout plans based on things like user preferences, injuries, and patterns in previous user feedback, and the like. Further, some embodiments may achieve this with a server architecture designed to serve a relatively large number of users bandwidth intensive video feeds).
Regarding claim 4, and substantially similar limitations in claims 11 and 18, King discloses wherein the instructions, when executed, cause the machine to: obtain a second video of an exercise participant performing the exercise; analyze, using the machine learning algorithm, the second video to determine metadata of the exercise participant performing the exercise; and compare the metadata to the exercise profile; and present an indication of the comparison via a graphical user interface (see para. [0087] In some embodiments, selection component 130 may be configured to select the second workout video block based on feedback from sensors 104. A second workout video block may be selected by comparing a sensor reading with a target value. In some cases, the sensor reading may be compared to a value expressed in the user profile, a value that corresponds to a fitness goal, a value that corresponds to a progression of a workout regimen. For example, selection component 130 may select a video intensity based on comparison of heart rate reading and a target heart rate in the user profile (e.g., a faster workout if the heart rate is lower that the target value, and a slower workout if the heart rate is higher than the target value). In another example, the second video block may be selected based on compliance of the user with the first video block (e.g., if a movement sensor detects that the user stopped following the video, a different type of workout may be selected for the second video). For instance, embodiments may reference workout stream to identify what type of exercise is next, and then select among video blocks within that type of exercise based on real-time feedback (e.g., feedback during or within a few minutes of completing an exercise).
See para. [0049] Families 220 may be grouped together within the video-block metadata data structure by block type. For example, as shown in FIG. 2, a block type group 230 may be a body-region. In some cases, a block type group may include families where the blocks contain exercises that target a specific body-region (e.g., lower body, upper body, core muscles, legs, arms, back, etc.). For example, a “Lower” group may contain a family of squats and a family of lunges.
See para. [0052] Or in some embodiments, the upper portion of FIG. 2, the stream 250 and the sets 240, may be encoded in a first data structure, e.g., one at least partially defining a sequence of a workout, while the lower portion (types 230, families 220, and blocks 210) may be defined in a second different data structure that organizes atomic units by which the first data structure partially or entirely defines a workout by referencing the second data structure).
Regarding claim 5, and substantially similar limitations in claims 12 and 19, King discloses wherein the instructions, when executed, cause the programmable circuitry to analyze, using the machine learning algorithm, the video to determine a starting partition for the exercise (see para. [0051] In some cases, a group of sets 240 may be referred to as a stream 250, where a stream is made of sets among which selections are made to compose video blocks for a complete workout. The user may choose to play a stream from start to finish. The user may choose the length of the stream. For example a full body stream may include warm-up (1), warm-up (2), warm-up (3), lower, then upper, cardio, full, core, cardio, cooldown 1, and cooldown 2. Other examples of stream include tone down stream, endurance stream, strength stream, core stream, recovery stream, or other streams).
Regarding claim 6, and substantially similar limitations in claims 13 and 20, King discloses wherein the instructions, when executed, cause the programmable circuitry to: obtain, via the user interface, a plurality of videos depicting the person performing the exercise (see para. [0061] Sensors 104 may be configured to generate output signals conveying information related to the user. In some embodiments, sensors 104 may include audiovisual sensors, activity sensors, physiological sensors, biometric sensors, or other sensors. Examples of such sensors may include a heart rate sensor, a blood pressure sensor/monitor, a weight scale, motion sensors, an optical sensor, biometric sensors, a video sensor, an audio sensor, a color sensor, a blood glucose monitor, a blood oxygen saturation monitor (e.g., a pulse oximeter), a hydration monitor, a skin/body temperature thermometer, a respiration monitor, electroencephalogram (EEG) electrodes, accelerometers, activity sensors/trackers, a GPS sensor, or other sensors. These examples should not be considered limiting. Sensors 104 are configured to generate various output signals conveying information related to the user that allows computing environment 100 to function as described herein. In some embodiments, sensors 104 may be disposed in a plurality of locations within or outside of computing environment 100. For example, sensors 104 may be on the user (e.g., wearable device), coupled with the client computing platforms 102, located in a medical device used by the user, positioned to point at the user (e.g., a video camera), or in other locations within or outside of computing environment 100. In some embodiments, information related to the user may be obtained through a combination of user input, user selection, sensor outputs, or other methods.
See par. [0062]: Information related to the user obtained from sensors 104 may include physiological information, behavior information, or other information obtained from sensors 104. Examples of physiological information may include heart rate, blood pressure, weight, pulse rate, blood chemistry, blood oxygen saturation, blood glucose level, hydration information, respiration rate, breathing information, skin/body temperature, brain activity, physical movement or lack of movement, activity duration information, physical pain information, or other physiological information. Examples of behavior information may include the user demeanor, voice, look, gestures, manners, attitude, or other behavior information. In some embodiments, user profile information may be updated based on information from sensors 104. For example, user profile information may be updated periodically, for example, user profile component 124 may be configured to periodically obtain information from sensors 104 and update the user profile information based on information from sensors 104. In some cases, the user may set the frequency of the update from the sensors. In some embodiments, the user profile information may be updated dynamically responsive to changes in information obtained from the sensors.
See para. [0091] In some embodiments, feedback may be obtained from a native application executing on the client computing devices to present videos, buffer videos, and communicate with servers 108 to effectuate workouts. In some cases, the application includes a user interface in which the video is displayed. In some embodiments, the user interface includes a plurality of inputs that, when selected by a user, cause messages indicative of a user input to be sent back to the servers 108 (or execute corresponding routines client side). In some embodiments, the inputs are regions of a screen overlaid on a video display, like touch-sensitive regions of a screen or clickable regions of a screen mapped to a corresponding event handler that is called upon a user input in the respective region. In some cases, the corresponding event handler may cause the client-side application to send a message back to the servers 108 indicative of the input); and
analyze, using the machine learning algorithm, the plurality of videos to detect the body position and the movement of the person performing the exercise (see para. [0084] In some embodiments, feedback component 150 may be configured to receive feedback from sensors 104. For example, feedback may be in the form of physiological, behavior, medical, or other information received from sensors 104. Examples of feedback received from sensors 104 may include heart rate, pulse rate, blood oxygen saturation, respiration rate, breathing information, physical movement or lack of movement, body position duration of movement, physical pain information, or other physiological information. Examples of behavior information may include the user demeanor, voice, look, gestures, manners, attitude, or other behavior information. For example, a feedback received from sensors 104 may indicate that the user is following the direction correctly based on his movement, body position, breathing, etc. Or, the feedback may indicate that the user is not following correctly (e.g., fall detection, or the user is breathing heavily, heart rate is too high, etc.).
Regarding claim 7, and substantially similar limitations in claims 14, King discloses wherein the instructions, when executed, cause the programmable circuitry to present a second user interface to obtain a modified to the exercise profile (see para. [0039] The personalized workout video creation servers 108 may include electronic storage 115, one or more processors 112, or other components. A single instance of the server 108 may serve personalized workout videos to a plurality of users concurrently in some cases. In the illustrated embodiment, the machine-readable instructions are shown as component of the processors 112 to indicate that the processors execute those instructions (e.g., with different processors executing different instructions), and in some embodiments, the instructions may be stored on a different component of a computer from the processors 112, for instance, in persistent storage or dynamic memory of a computer housing the processor, the memory, and the storage. In some cases, the server 108 is a web server configured to interface with a client-side web browser or an application program interface server operative to interface with a client-side native application. Personalized workout video creation servers 108 may include communication lines, components, or ports to effect the exchange of information with a network or client computing platforms 102. Illustration of personalized workout video creation servers 108 in FIG. 1 is not intended to be limiting, which is not to imply that other descriptions herein are limiting. Personalized workout video creation servers 108 may include a plurality of hardware, software, or firmware components operating together to provide the functionality attributed herein to personalized workout video creation servers 108. For example, personalized workout video creation servers 108 may be implemented by a plurality of virtualized computing instances executing in a remote data center operating together as personalized workout video creation servers 108).
Claim Rejections - 35 USC § 112
Claims rejected under 35 U.S.C. § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor at the time the application was filed, had possession of the claimed invention.
Claim 1, and substantially similar limitations in claims 8 and 15, recites “analyze, using a machine learning algorithm, the video to detect a body position and a movement of the person performing the exercise.”
When examining computer-implemented functional claims, examiners should determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. An algorithm is defined, for example, as "a finite sequence of steps for solving a logical or mathematical problem or performing a task." Microsoft Computer Dictionary (5th ed., 2002). Applicant may "express that algorithm in any understandable terms including as a mathematical formula, in prose, or as a flow chart, or in any other manner that provides sufficient structure." Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1340, 86 USPQ2d 1609, 1623 (Fed. Cir. 2008) (internal citation omitted). It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015) (reversing and remanding the district court’s grant of summary judgment of invalidity for lack of adequate written description where there were genuine issues of material fact regarding "whether the specification show[ed] possession by the inventor of how accessing disparate databases is achieved"). If the specification does not provide a disclosure of the computer and algorithm in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention a rejection under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, for lack of written description must be made.
In the present case, the specification does not provide a disclosure of the algorithm (i.e. “analyze, using a machine learning algorithm, the video to detect a body position and a movement of the person performing the exercise”) in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention. Therefore, claims 1, 8 and 15 are rejected under 35 U.S.C. § 112(a), as failing to comply with the written description requirement. Claims 2-7, 9-14 and 16-20 are also rejected under 35 U.S.C. § 112(a), based on their respective dependencies to claim 1, 8 or 15.
Claims rejected under 35 U.S.C. § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 1, and substantially similar limitations in claims 8 and 15, recites “an indication of a characteristic for an exercise.” A claim is indefinite when the boundaries of the protected subject matter are not clearly delineated and the scope is unclear. In the present case, the terms “an indication” and “characteristic” in the context of “exercise” are so broad, the scope is unclear. Arguably, a rejection under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, would be appropriate since the terms within the context as claimed are unsupported and lack enablement. See MPEP § 2173.04. Therefore, claims 1, 8 and 15 are rejected under 35 U.S.C. § 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention. Claims 2-7, 9-14 and 16-20 are also rejected under 35 U.S.C. § 112(a), based on their respective dependencies to claim 1, 8 or 15.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT P. BULLINGTON whose telephone number is (313) 446-4841. The examiner can normally be reached on Monday through Friday from 8 A.M. to 4 P.M. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Peter Vasat, can be reached on (571) 270-7625. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at (866) 217-9197 (toll-free).
/Robert P Bullington, Esq./ Primary Examiner, Art Unit 3715
Prosecution Insights