DETAILED ACTION
Claims 1-20 are pending. This is in response to the application filed on November 5, 2024.
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 .
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-11 and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Pub 20230062244 (hereinafter Holland) in view of Pub 20250350935 (hereinafter Kunz)
Regarding claim 1, Holland discloses a method comprising:
determining an instruction configured to cause an endpoint device to execute an operation (Fig. 6B and par. [0122]-[0126] disclose an RX system to control a computing device such as an IoT device and/or an XR device, a virtual reality (VR) device, an augmented reality (AR) device, etc. by sending a signed command message);
Holland does not expressly disclose determining a cryptographic signature based on the instruction. Kunz discloses this features (par. [0080] disclose a command request message comprises a nonce, a command, and a signature where generating a key based on a secret parameter and the nonce, generating a signature using the generated security key and the command as input parameters). Therefore, it would have been obvious before the effective filing date of the claim invention to modify Holland with Kunz to teach the aforementioned claimed feature. One would have done so using known process taught by Kunz in the same field of endeavor for sending signed command messages between devices with reasonable expectation of success.
generating an instruction payload comprising the instruction and the cryptographic signature (par. [0125]); and
transmitting the instruction payload to the endpoint device by way of a multi-party server, wherein the instruction is executable by the endpoint device when the cryptographic signature in the instruction payload is verified by the endpoint device based on the instruction in the instruction payload (par. [0125]-[0126]. Note, the XR system comprises one or more devices/servers (Fig. 1 and par. [0054]) to control a plurality of XR devices).
Regarding claim 2, Holland discloses “the XR system 100 can be part of, or implemented by, a single computing device or multiple computing devices…” (par. [0054]). Hence, having one device among multiple computing devices in the XR system (e.g. a dedicate server among other servers) to provide each of the instruction, the cryptographic signature, and the instruction payload is determined by a single-party computational instance of a remote network management platform, and wherein the endpoint device is configured to communicate with the single-party computational instance by way of the multi-party server is possible. Therefore, it would have been obvious before the effective filing date of the claim invention to modify Holland to teach the aforementioned claimed feature. One would have done so as an obvious variation for using one device to perform a function among a plurality of devices in the XR system.
Regarding claim 3, Holland discloses wherein the cryptographic signature is determined using a private key of the single-party computational instance, and wherein the cryptographic signature in the instruction payload is verifiable by the endpoint device using a public key that corresponds to the private key and has been provided by the single-party computational instance to the endpoint device without transmission through the multi-party server (as presented in claim 1 rejection, the XR system signs the command message meaning a private key of the XR system is used for signing. Since a device (e.g. namely a dedicate server as suggested in claim 2 rejection) in the XR system provides the instruction, the cryptographic signature, and the instruction payload as presented in claim 2 rejection, this same device/server should use its own private key for signing).
Regarding claim 5, Holland discloses determining a shared instruction list comprising one or more instructions that comprise the instruction and are assigned for execution by one or more endpoint devices that comprise the endpoint device (par. [0104] discloses a shared key used to control more than one device);
determining, for each respective endpoint device of the one or more endpoint devices, a corresponding endpoint-specific instruction list comprising at least one identifier of at least one instruction from the shared instruction list assigned for execution by the respective endpoint device (par. [0107] discloses a signed command can include a command to turn off a particular smart light bulb, change a light level of the smart light bulb, etc.);
determining the cryptographic signature comprises: determining, for each respective instruction in the shared instruction list, a corresponding instruction signature based on the respective instruction (par. [0092] discloses the biometric data can be included in the signed control message and the signed control message can represent multiple messages. Moreover, par. [0100] discloses a device can use to control any of the multiple computing devices. Thus, Holland teaches same instruction, for example turning on a light bulb, can be sent to multiple devices where each device is distinguished by their own output patterns that used to encode the signing key); and determining, for each respective endpoint device of the one or more endpoint devices, a corresponding endpoint signature based on the corresponding endpoint-specific instruction list, wherein the at least one instruction in the corresponding endpoint-specific instruction list is executable by the respective endpoint device when both the corresponding instruction signature and the corresponding endpoint signature in the instruction payload are verified by the endpoint device (as presented above and in claim 1 rejection, each device verifies the signed command).
Regarding claim 6, Holland discloses wherein the instruction as transmitted to the endpoint device by way of the multi-party server is executable by the endpoint device when a corresponding identifier of the instruction is included in the corresponding endpoint-specific instruction list of the endpoint device (the biometric data, output pattern, etc. as identifiers are included in the message).
Regarding claim 7, Holland discloses wherein the one or more instructions of the shared instruction list comprise a plurality of instructions (par. [0092]), wherein the one or more endpoint devices comprise a plurality of endpoint devices (there is more than one device to be controlled in a device (Fig. 1 and par. [0069] discloses a device 150 is an IoT device which can have a plurality of output devices 160 such as a display, a speaker, a microphone, an image sensor, an LED device, etc.)), wherein a first subset of the plurality of instructions is assigned for execution by the endpoint device, wherein a second subset of the plurality of instructions is assigned for execution by another endpoint device of the plurality of endpoint devices, and wherein the second subset is different from the first subset (par. [0096] discloses a signed command can include one or more commands/instructions for controlling an operation(s) and/or state(s) of the computing device. Thus, different commands can be used to send to another device if it is a different IoT device).
Regarding claim 8, Holland discloses wherein the one or more instructions of the shared instruction list comprise a plurality of instructions, wherein the one or more endpoint devices comprise a plurality of endpoint devices (Fig. 1 and related text discloses a device 150 is an IoT device which can have a plurality of output devices 160 such as a display, a speaker, a microphone, an image sensor, an LED device, etc. which can be used to be activated by a command corresponding to each device), wherein the multi-party server is configured to provide, to each respective endpoint device of the plurality of endpoint devices, (i) the corresponding endpoint-specific instruction list and (ii) a subset of the shared instruction list, wherein the subset of the shared instruction list comprises each operation included in the corresponding endpoint-specific instruction list (see above reasoning and claim 7 rejection).
Regarding claim 9, Holland discloses wherein the instruction payload comprises (i) the shared instruction list (ii), for each respective instruction in the shared instruction list, the corresponding instruction signature, (iii) the corresponding endpoint-specific instruction list for each respective endpoint device, and (iv), for each respective endpoint in the corresponding endpoint-specific instruction list, the corresponding endpoint signature (see claims 5-8 rejections).
Regarding claim 10, Holland discloses wherein each of (i) the corresponding instruction signature of each respective instruction in the shared instruction list and (ii) the corresponding endpoint signature of each respective endpoint device of the one or more endpoint devices is generated using a shared cryptographic key (par. [0104]).
Regarding claim 11, Holland discloses wherein the corresponding instruction signature of each respective instruction in the shared instruction list is generated using a first cryptographic key, and wherein the corresponding endpoint signature of each respective endpoint device of the one or more endpoint devices is generated using a second cryptographic key that differs from the first cryptographic key (each device receives a command message can be shared with a key or different key).
Regarding claim 13, Holland and Kunz disclose wherein the instruction is executable by the endpoint device when the cryptographic signature in the instruction payload is verified by the endpoint device by determining that the cryptographic signature matches a second cryptographic signature determinable by the endpoint device based on the instruction in the instruction payload (see claim 1 rejection).
Regarding claim 14, Kunz discloses wherein generating the instruction payload comprises: encrypting at least part of the instruction, wherein the instruction is executable by the endpoint device after decryption of the at least part of the instruction by the endpoint device (par. [0070] discloses encrypting command parameters).
Regarding claim 15, Holland discloses wherein, based on obtaining the instruction payload, the multi-party server is configured to determine an endpoint-specific instruction payload that includes the instruction, the cryptographic signature, and directions for obtaining, by the endpoint device, software code for executing the instruction (par. [0121]-[0126] discloses the command is generated by output pattern (light, audio, etc.). That is if the XR system detects the device is a light bulb, for example, it will emit light then the command to be sent to turn off the light).
Regarding claim 16, Holland discloses wherein: the operation comprises an operating system function; the operation comprises a function of a plug-in executable by the endpoint device; or the operation forms part of a discovery pattern (par. [0052] discloses the command can be a function sent to a device executed within its capability (e.g. turning on or off a light bulb but cannot be a command function to ask the light bulb to generate sound).
Regarding claim 17, Kunz discloses wherein the instruction comprises a parameter value of a parameter to be used by the endpoint device in execution of the operation (par. [0080]).
Regarding claim 18, Holland discloses prior to determining the instruction, providing, to the endpoint device, a software application configured to receive instruction payloads obtained from the multi-party server and facilitate execution of instructions contained in the instruction payloads (the RX system generates a command message only when it (e.g. an application in the XR system) detects output patterns of a device).
Claims 19-20 are rejected in view of claim 1 rejection.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable Holland in view of Kunz and further in view of Patent 11025481 (hereinafter Louca)
Regarding claim 4, Holland discloses the communication between the XR system and a device (Fig. 2B shows the XR systema 100 and a computing device 150). Holland does not expressly disclose if there is a module to process received messages in the device as a message broker. Louca disclose an alert manager that can be implemented as a software component to process received messages (Fig. 1, col. 2: “The alert manager 110 can comprise one or more software and/or hardware components of one or more computing devices. The alert manager 110 is configured to receive alert messages (e.g., 146 and 148). The alert manager 110 can be connected to a computer network and can receive the alert messages from one or more computing devices…). Therefore, it would have been obvious before the effective filing date of the claimed invention to modify Holland and Kunz with Louca to further teach wherein the single-party computational instance is configured to transmit the instruction payload to the multi-party server through a message broker, wherein execution of the operation by the endpoint device causes the endpoint device to generate output data, wherein the endpoint device is configured to transmit the output data to the message broker by way of the multi-party server, and wherein the single-party computational instance is configured to obtain the output data from the message broker asynchronously with the transmission of the output data to the message broker by the endpoint device. One would have done so using known method to arrive at the claimed invention with reasonable expectation of success.
Allowable Subject Matter
Claim 12 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Inquiry communication
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRI M TRAN whose telephone number is (571)270-1994. The examiner can normally be reached Mon-Fri: 9am-5pm.
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, Jeffrey Nickerson can be reached at (469)295-9235. 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.
/TRI M TRAN/Primary Examiner, Art Unit 2432
Prosecution Insights