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 .
Response to Arguments
Applicants’ arguments filed 06/01/2026 have been fully considered but they are not persuasive.
On page 8 applicant argues that Braun fails to teach automatically transmitting the retained control instruction when the other process becomes the focus process without a further request. Applicant arguments have been considered but are not persuasive. Braun expressly discloses that commands from an inactive foreground application col 20, line 34-36 “the commands from an inactive foreground application can be stored and then sent to the device when the application becomes active.” Braun further explains that when a different application becomes active, the API indicates the change to the context driver, which loads the effects from the newly active context to the force feedback device, and that when the original application again becomes active, the API instructs the context driver to activate the associated context and load the appropriate effects. Thus, Braun’s previously stored command/effect is transmitted in response to the application becoming active, without Braun requiring the application to output another command after becoming active.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-10 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Braun (US 6300936 B1) in view of Braun.
Regarding claim 1, Braun teaches:
An information processing apparatus configured to connect to an operation device comprising an operation member, the information processing apparatus comprising one or more processors; and a storage device storing a program which, when executed by the one or more processors, cause the information processing apparatus to perform operations comprising(Claim 52. A force feedback interface device coupled to a host computer displaying a graphical environment and a user-controlled graphical object within said graphical environment on a display device, the interface device comprising. See also col 17, line 4-13)
executing a plurality of processes in parallel, wherein the plurality of processes comprises a first process executing an application program and a second process executing a system (col 16, line 34-43 FIG. 4 is a block diagram of a preferred architecture for the host computer to communicate with and control a force feedback interface device 11 with multiple application programs running on the host computer. Application programs 202 and 204 are concurrently running on the host computer 18. In the most typical implementation, one of the application programs is actively running in an operating system as the "active" application program that displays one or more active windows in the GUI (also known as the application program that is "in focus" or which has "keyboard focus").)
selecting a process among the plurality of processes as a focus process based on a given condition. (col 16, line 34-50. FIG. 4 is a block diagram of a preferred architecture for the host computer to communicate with and control a force feedback interface device 11 with multiple application programs running on the host computer. Application programs 202 and 204 are concurrently running on the host computer 18. In the most typical implementation, one of the application programs is actively running in an operating system as the "active" application program that displays one or more active windows in the GUI (also known as the application program that is "in focus" or which has "keyboard focus"). The active window is typically the topmost displayed window in which input is provided by the user using the mouse-controlled cursor, a keyboard, or other peripheral. The other applications are "inactive" in that they are not receiving input from the user (although they may have a window displayed in the GUI which can be updated on the screen))
generating, by the plurality of processes, a plurality of control instructions, wherein each control instruction of the plurality of control instructions indicates a content of a control process to be executed by a component of the operation device (col 20, line 6-13. The context driver 210 receives individual effects and events as they are created by the application program using API 208 and stores the effects and events in a context list 212, storing each context in a different storage location in the host's memory or on some other type of storage device. An active or inactive application program can create a context and have it stored, but only the active application's context will be sent to the force feedback device.)
transmitting, to the operation device, a first control instruction of the plurality of control instructions in response to a setting request from the focus process. (col 20, line 52-67. A context is therefore only allowed to exert forces with the force feedback device when that context is active, i.e., is associated with an active application program or the background application. In the described embodiment, only one foreground context can be active at any given time. Any number of background contexts may be simultaneously active; however, there may be a device limit on the number of background contexts that may be created. For example, the mouse device 11 may only allow one background context to be created at any one time, which is the preferred embodiment. Thus, if an inactive (not in focus) foreground application program commands a force to be output, the API will ignore the command after determining that the commanding application is not active (or, the command will only be sent to the device when the application becomes active).)
restricting transmission of a second control instruction of the plurality of control instructions in response to a setting request another process of the plurality of processes other than the focus process, and retaining a content of the setting request from the other process; and (col 20, line 36-52. If the application is active or background, the API sends the start information to the context driver 210 indicating the application program that commanded the force and the particular force effects to be commanded. The context driver 210 then associates the commanding application program with a context 214 in list 212 and sends the effects from the context to the force feedback device (if not previously sent). For example, if a context for a particular application program includes a spring effect, a damper effect, and a vibration effect, and the application program commands the vibration to be output, then the context driver selects the vibration effects to be output to the device. The data describing this effect is then output by the context driver 210. Similarly, the application program can send a command to stop particular force effects, to pause the effects, to get the status information of an effect, or to destroy an effect.)
Braun teachings does not appear to explicitly teach : and retaining a content of the setting request from the other process; and automatically transmitting the second control instruction in response to the retained content of the setting request from the other process when the other process is newly selected as a focus process without a further setting request being output by the other process after being newly selected as the focus process.
However, Braun does teach :(col 20,line 63 – col 21, line 10. Thus, if an inactive (not in focus) foreground application program commands a force to be output, the API will ignore the command after determining that the commanding application is not active (or, the command will only be sent to the device when the application becomes active).If the active application program becomes inactive (i.e. loses foreground or is removed from the host's memory) and a different application becomes active, then the API indicates this to the context driver 210, which then deactivates the context associated with that application program and loads the effects from the new active context to the force feedback device 11. Likewise, when the original application program again becomes active, the API tells the context driver to activate the associated context and load the appropriate effects to the force feedback device.).
Accordingly, it would have been obvious to one of ordinary skill in art before the effective filing of the invention to ignore (restrict) an inactive application to ensure only the active selected process by the user controls the haptic device. This behavior is a standard feature in multitasking systems.
Regarding claim 2, Braun teaches:
The information processing apparatus according to wherein the operations further comprise: selecting a process that is an object for accepting a user's operation from the plurality of processes as the focus process. (col 16, line 63- col 17, line 16 . When the user moves the cursor over an inactive window and provides a command gesture such as clicking a button on a mouse, the inactive window becomes the active window and the former active window becomes inactive. The active application is also known as the "foreground" application, in the sense that its force sensations are being implemented by the force feedback device, as described below. A master application 206 also is running on host computer 18 and is also known as the "background" force feedback application. This application is preferably a general purpose program that always runs inactively in the operating system and whose set of commanded forces are always available to be output and controlled on the interface device 11 and/or other devices. For example, a preferred embodiment of the master application is a "desktop" control panel for force feedback. An example of such a program is illustrated in FIG. 5. A "mouse properties" dialog box 240 can be displayed which allows the user to specify force sensations 244 that are assigned to specified object types 242 in the displayed graphical environment, e.g. a graphical user interface )
Regarding claim 3, Braun teaches:
The information processing apparatus according to The information processing apparatus according to wherein the operations further comprise: periodically receiving state information indicating an execution state of the control process from the operation device;, (col 20, line 48 – 66. The data describing this effect is then output by the context driver 210. Similarly, the application program can send a command to stop particular force effects, to pause the effects, to get the status information of an effect, or to destroy an effect. A context is therefore only allowed to exert forces with the force feedback device when that context is active, i.e., is associated with an active application program or the background application. In the described embodiment, only one foreground context can be active at any given time. Any number of background contexts may be simultaneously active; however, there may be a device limit on the number of background contexts that may be created. For example, the mouse device 11 may only allow one background context to be created at any one time, which is the preferred embodiment. Thus, if an inactive (not in focus) foreground application program commands a force to be output, the API will ignore the command after determining that the commanding application is not active (or, the command will only be sent to the device when the application becomes active).)
Regarding claim 5, Braun teaches the elements of claim 1 as outline above and thus the claim has similar limitations and is rejected under the same rationale provided above. Braun also teaches:
A method for controlling an information processing apparatus connected to an operation device comprising an operation member,, the method comprising. ( Claim 1. A method for interfacing a multi-tasking graphical environment implemented on a host computer with a force feedback interface device coupled to said host computer, wherein multiple application programs are simultaneously running in said multi-tasking environment, wherein one of said multiple application programs is active and the other application programs are inactive, the method comprising)
Regarding claim 6, Braun teaches the elements of claim 1 as outline above and thus the claim has similar limitations and is herein rejected under the same rationale provided above.. Braun also teaches::
A non-transitory, computer readable storage medium containing a computer program, which when executed by a computer connected to an operation device comprising an operation member,, causes the computer to carry out actions, comprising. (Claim 16 A computer readable medium including program instructions executable by a host computer:)
Regarding claim 7, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 8, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 9, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 10, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 15, Braun teaches:
The information processing apparatus of claim 1, wherein the operations further comprise transmitting a control instruction to reset a current operation mode of the operation device in a case where a focus process is newly selected and a setting request has not been previously received from the newly selected focus process. (col 21, line 1-10, If the active application program becomes inactive (i.e. loses foreground or is removed from the host's memory) and a different application becomes active, then the API indicates this to the context driver 210, which then deactivates the context associated with that application program and loads the effects from the new active context to the force feedback device 11. Likewise, when the original application program again becomes active, the API tells the context driver to activate the associated context and load the appropriate effects to the force feedback device. Col 22, line 6-12. The translation layer outputs device messages 225 to the device 11 by way of the next layer. Messages may include force effects to be output and/or any other information such as device identification numbers or instructions from the context driver for an effect (start, stop, pause, reset, etc.) The translation layer outputs messages 225 in a form the device 11 can understand.)
Regarding claim 16, Braun teaches:
The information processing apparatus of claim 1, wherein the given condition for selecting the focus process comprises a user operation of a system button provided on the operation device. (FIG. 4 is a block diagram of a preferred architecture for the host computer to communicate with and control a force feedback interface device 11 with multiple application programs running on the host computer. Application programs 202 and 204 are concurrently running on the host computer 18. In the most typical implementation, one of the application programs is actively running in an operating system as the "active" application program that displays one or more active windows in the GUI (also known as the application program that is "in focus" or which has "keyboard focus"). The active window is typically the topmost displayed window in which input is provided by the user using the mouse-controlled cursor, a keyboard, or other peripheral. The other applications are "inactive" in that they are not receiving input from the user (although they may have a window displayed in the GUI which can be updated on the screen). The inactive applications may also receive input or send output)
Regarding claim 17, Braun teaches:
The information processing apparatus of claim 1, wherein the second process executing the system program displays a system screen for presenting a processing result on a display device while the first process continues to execute in a background of the system program. (col 16, line 34-51. FIG. 4 is a block diagram of a preferred architecture for the host computer to communicate with and control a force feedback interface device 11 with multiple application programs running on the host computer. Application programs 202 and 204 are concurrently running on the host computer 18. In the most typical implementation, one of the application programs is actively running in an operating system as the "active" application program that displays one or more active windows in the GUI (also known as the application program that is "in focus" or which has "keyboard focus"). The active window is typically the topmost displayed window in which input is provided by the user using the mouse-controlled cursor, a keyboard, or other peripheral. The other applications are "inactive" in that they are not receiving input from the user (although they may have a window displayed in the GUI which can be updated on the screen). The inactive applications may also receive input or send output. See also col 16, line 51- col 17, line 52)
Claims 11-12 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Braun (US 6300936 B1) in view of Braun and in further view of Lacroix (US 20150130706 A1).
Regarding claim 11, Braun does not appear to explicitly teach:
The information processing apparatus of claim 1, wherein the operation member is a trigger button comprising a movable portion, and the component of the operation device is a force sense presentation mechanism configured to apply a force to the movable portion.
However, Lacroix teaches: [0051] Controller 30 can further include one or more digital buttons, one or more analog buttons, one or more bumpers, one or more directional pads, one or more analog or digital sticks, one or more driving wheels, and/or one or more user input elements that can be interacted with by a user, and that can provide input to system 10. Controller 30 can also include one or more analog or digital trigger buttons (or "triggers") that can further be interacted with by the user, and that can further provide input to system 10. As is described below in greater detail, controller 30 can further include a motor, or another type of actuator or haptic output device, configured to exert a bi-directional push/pull force on at least one trigger of controller 30. See also [0052],[0069-0071]
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Braun’s force feedback operation device and Lacroix’s haptic enable trigger, including an actuator configured to apply force to the trigger and to vary the trigger haptic effect based on the position and range of the trigger, in order to provide localized and responsive force feedback at the trigger and thereby provide more realistic and immersive gaming experience as taught by Lacroix[0162] .
Regarding claim 12, Lacroix teaches:
The information processing apparatus of claim 11, wherein the control process includes presenting a force sense to the trigger button in an amount determined according to an operation amount of the trigger button. ([0065] Device 500 further includes trigger engine 506. Trigger engine 506 can receive haptic data, such as a trigger haptic effect definition, and can modify the haptic data based on data, such as trigger data (e.g., trigger data 513 as illustrated in FIG. 5) received from controller 520. Trigger data is data that includes one or more parameters that indicate a position and/or range of one or more triggers of controller 520 (e.g., triggers L and R as illustrated in FIG. 5). See also [0054])
Regarding claim 18, the claim recites similar limitation as corresponding claim 11 and is rejected for similar reasons as claim 11 using similar teachings and rationale.
Regarding claim 19, the claim recites similar limitation as corresponding claim 12 and is rejected for similar reasons as claim 12 using similar teachings and rationale.
Claims 13-14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Braun (US 6300936 B1) in view of Braun and in further view of Grant (US 20130147610 A1).
Regarding claim 13, Braun does not appear to explicitly teach:
The information processing apparatus of claim 1, wherein each control instruction specifies one of a plurality of predetermined operation modes, the plurality of operation modes comprising a trigger mode for simulating a trigger of a gun and a vibration mode for presenting vibration to the operation member.
However, Grant teaches: [0024] When used in conjunction with a gaming device, a multi-stage variable resistance trigger assembly may provide a more realistic gaming experience. For example, in a first-person shooting game, multiple stages may provide a feel to the user approximating the feel of the trigger assembly on a real weapon. Specifically, the transition between a first stage and a second stage may be substantially discontinuous as to mimic the "release" of a real gun trigger while firing of a real bullet. [0037] The trigger resistance information may be consistent during a single use of the computing device. The computing device may specify trigger resistance information according to one or more settings of software (e.g., a video game) executing on the computing device. For example, if the software is a first-person shooting game, a multi-stage resistance profile (e.g., profile 410 of FIG. 4) may be specified to mimic the feel of a trigger pull of a weapon.[0038] In other embodiments, the trigger resistance information may vary throughout a single use of the computing device. Settings may specify different resistance profiles for use in different segments of the same game or other application. For example, returning to the shooting game scenario, a multi-stage resistance profile (e.g., profile 410 of FIG. 4) may be specified for a first part of the game (e.g., firing a rifle), while a standard profile (e.g., profile 402 of FIG. 4) may be specified for a second part of the game (e.g., driving a vehicle).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to include Grant’s multistage weapon trigger resistance profile in Braun’s force feedback operation device so that during a shooting game, the trigger provides resistance and a release sensation operation and firing of an actual weapon thereby providing a more realistic gaming experience as taught by Grant [0024]
Regarding claim 14, Grant teaches:
The information processing apparatus of claim 13, wherein the trigger mode comprises a transition between a standby state, a pulling state in which a repulsive force is presented, and a fired state in which the repulsive force is removed. ([0027] FIG. 2 shows a non-limiting example of a multi-stage variable resistance trigger assembly 200. Assembly 200 includes a trigger 202 at a rest position (illustrated by pull indicator 204a). It will be understood that the term "rest position" as used herein refers to the position of the trigger assembly absent an applied external force. Trigger 202 is mechanically coupled to button actuator 206. Button actuator 206 includes a guide 208 in which a pivot 210 of trigger 202 is configured to move. In other embodiments, trigger 202 may be coupled to button actuator 206 in another suitable manner. [0053] During the beginning range of a trigger pull, striker plate 618 is adjacent to magnet 602. As such, a magnetic force resists separation of striker plate 618 from magnet 602. [0054] Assembly 600 further includes tension spring 620 coupled to both slider assembly 614 and magnet 602. As such, it will be understood that magnet 602 may include a non-magnetic layer or housing in order to provide such coupling. The non-magnetic material coupled to magnet 602 may further allow magnet 602 to move within slider assembly 614, as will be discussed below. The tension spring 620 provides a force acting on magnet 602. Said force is less than the attractive force between magnet 602 and striker plate 618, such that magnet 602 remains magnetically coupled to striker plate 618 throughout a beginning range of the pull of trigger 606 (including the "rest" position). See also [0055])
Regarding claim 20, the claim recites similar limitation as corresponding claim 13 and is rejected for similar reasons as claim 13 using similar teachings and rationale.
Conclusion
Grant (US 20130331157 A1) – is relevant to haptic enable gun triggers and trigger position force feedback.
Oshima (US 20160256774 A1) – is relevant to controller home button for invoking system level functions and displaying different screens of applications.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m 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 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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights