DETAILED ACTION
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 AMENDMENT
Claim rejections based on prior art
Applicant’s arguments filed 02/24/2025 with respect to claims 1-20 have been fully considered but are not persuasive.
Pages 9 and 10 of Applicant’s remarks disclose “responsive to attachment of the first pluggable hardware module to the server via a particular externally-accessible slot of the set of externally-accessible slots of the enclosure of the server, detect that the first pluggable hardware module has been attached to the server via the particular externally-accessible slot of the set of externally-accessible slots of the enclosure of the server,” as recited in amended claim 1”.
Please note, since claim 1 recites ‘a set of externally-accessible slots for attaching one or more pluggable hardware modules…’, see paragraph 0055 of Asgekar, which described network interface 118 as an express card network card, understood to include multiple slots. Please note, the claim language doesn’t limit a ‘set’ of slots as multiple slots that are connected to multiple modules concurrently.
With respect to claim language “responsive to attachment of the first pluggable hardware module to the server via a particular externally-accessible slot of the set of externally-accessible slots of the enclosure of the server”, see paragraphs 0097 and 0098 of Asgekar, which discloses interface 208, network interface 118, as a physical built-in network adapter that a client is connected/attached to.
With respect to claim language “detect that the first pluggable hardware module has been attached to the server via the particular externally-accessible slot of the set of externally-accessible slots of the enclosure of the server”, see paragraphs 0097 and 0098, which discloses interface 208, network interface 118, as a physical built-in network adapter that a client is attached to and transmitting data. For example, paragraph 0098 discloses “the interface 208 can receive one or more requests, media streams (e.g., feeds), instructions, commands (e.g., to reject or accept media streams from one or more devices), or electrical signals from devices within the system 200 (e.g., client devices 203 or administrator device 204). The interface 208 can transmit data packets, information, or electrical signals to the devices”. Note, the result/function of a client device transmitting data via interface 208, network interface 118 is being equated to a result/function of a determination, detection; in other words, communication takes place as a result of a determination, detection that there is a physical connection, attachment. The claim language is not calling for a specific process of a ‘detect, detection, determination’.
Pages 10 and 11 of Applicant’s remarks disclose “The reference also fails to teach or suggest “in response to determining that the first pluggable hardware module that has been attached to the server via the particular externally-accessible slot of the enclosure of the server is in a list of approved pluggable hardware modules configured to physically attach to the server via the particular externally-accessible slot of the enclosure of the server, obtain a first digital certificate from the first pluggable hardware module,” as recited in amended claim 1.”
With respect to a ‘list of approved pluggable hardware modules configured to physically attach to the server via the particular externally-accessible slot of the enclosure of the server’, Please note, a connected client on network interface 118/208, being on the list of users with access or permission to a session, as disclose in paragraphs 0099 and 0129 of Asgekar, is being equated to claim language of being ‘in a list of approved pluggable hardware modules configured to physically attach to the server via the particular externally-accessible slot of the enclosure of the server’.
Also, a first key, as discloses in paragraph 0100 of Asgekar, is being equated to claim first digital certificate; therefore, see paragraph 0100 of Asgekar, which discloses “for example, the hash generator 212 can receive a first hash computed using session metadata and signed with a first key from the client device 203”.
With respect to claim language ‘wherein the list of approved pluggable hardware modules configured to attach to the server via the particular externally-accessible slot is included in the metadata’, see paragraph 0099 of Asgekar, which discloses “the metadata of the session can include a list of users with access or permission to the session”.
With regards to the other independent claims 6 and 16, see responses above.
REJECTIONS BASED ON PRIOR ART
Claim Rejections - 35 USC § 102
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.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
1. Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Asgekar et al. (US pub. # 2023/0143579), hereinafter, “Asgekar”.
At the outset, Applicant is reminded that claims subject to examination will be given their broadest reasonable interpretation in light of the supporting disclosure. In re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023,1027-28 (Fed. Cir. 1997). With this in mind, the discussion will focus on how the terms and relationships between the terms in the claims are met by the references.
2. As per claims 1, 6 and 16, Asgekar discloses a system (network environment of fig. 1A), comprising: a server (server 106 of fig. 1A) which includes a primary processor (CPU 121 of fig. 1C, in a server, as discloses in paragraph 0044) and a memory (main memory 122), wherein an enclosure within which the primary processor and the memory are incorporated comprises a set of externally-accessible slots (network interface 118; see paragraph 0055, which described network interface 118 as an express card network card, understood to include multiple slots. Please note, the claim language doesn’t limit a ‘set’ of slots as multiple slots that are connected to multiple modules concurrently) for attaching one (a client 102, as discloses in paragraph 0044) or more pluggable hardware modules to the server without disassembly of the enclosure (see paragraphs 0055 and 0097); a first pluggable hardware module (a first client 102 of figs. 1A and 1C) comprising a first auxiliary processor (CPU 121 of fig. 1C, in a first client) for executing at least a portion of a first application (see paragraphs 0044 and 0054); and a second pluggable hardware module (a second client 102 of fig. 1A) comprising a second auxiliary processor (CPU 121, in a second client) for executing at least a portion of a second application (see paragraphs 0044 and 0054); wherein the memory stores program instructions that when executed on the primary processor: cause, in response to input received via one or more programmatic interfaces, metadata [see paragraph 0087, which discloses “the session data 228 can include, store, or maintain data (e.g., metadata) related to a session (e.g., breakout session). The data can include at least session identifier, session layout, interface in the session, devices connected to the session, whiteboard data (e.g., text or images fixed on the whiteboard) shown to users within a session, logs of activities performed by one or more client devices 203 including at least timestamps, pointer location, or mouse click, among other information to generate or update the session for users. The session data 228 can include, store, or maintain data related to other sessions within an institution. The session data 228 can be accessed or retrieved by one or more devices 203”] pertaining to a set of approved pluggable hardware modules to be stored in an encrypted read-write portion [data repository 224 of fig. 2, as disclose in paragraphs 0068 and 0081, specifically paragraph 0081, which discloses “the servers 206 can include features and functionalities that are a part of the media server 201. The servers 206 can communicate with the media server 201 to exchange data or information (e.g., between a database of the server 206 and the data repository 224 of the media server 201), forward data from other components of the system 200, or transmit or receive processed information”] of boot media of the server [see paragraph 0129, which discloses “the API server 508 and SFU 516 can share a secret key (e.g., cryptographic key or session key). When a client 512 requests registration for a session (e.g., step 520), the API server 508 can fetch the metadata for the session from the database 504. Based on the metadata, the API server 508 can perform a lookup of the session permission to determine if the client 512 has access to the session being requested (e.g., step 524). The API server 508 can retrieve the session metadata from the database 504 (e.g., at step 528)”]; responsive to attachment of the first pluggable hardware module to the server via a particular externally-accessible slot of the set of externally-accessible slots of the enclosure of the server (see paragraphs 0097 and 0098, which discloses interface 208, network interface 118, as a physical built-in network adapter that a client is connected/attached to), detect that the first pluggable hardware module has been attached to the server via the particular externally-accessible slot of the set of externally-accessible slots of the enclosure of the server [see paragraphs 0097 and 0098, which discloses interface 208, network interface 118, as a physical built-in network adapter that a client is attached to and transmitting data. For example, paragraph 0098 discloses “the interface 208 can receive one or more requests, media streams (e.g., feeds), instructions, commands (e.g., to reject or accept media streams from one or more devices), or electrical signals from devices within the system 200 (e.g., client devices 203 or administrator device 204). The interface 208 can transmit data packets, information, or electrical signals to the devices”. Note, the result/function of a client device transmitting data via interface 208, network interface 118 is being equated to a result/function of a determination, detection; in other words, communication takes place as a result of a determination, detection that there is a physical connection, attachment. The claim language is not calling for a specific process of a ‘detect, detection, determination’]; in response to determining (please note, the claim language is not calling for a specific process, step(s) in ‘determining’) that the first pluggable hardware module that has been attached to the server via the particular externally-accessible slot of the enclosure of the server is in a list of approved pluggable hardware modules configured to physically attach to the server via the particular externally-accessible slot of the enclosure of the server (see paragraphs 0099 and 0129. Please note, a connected client on network interface 118/208, being on the list of users with access or permission to a session, as disclose in paragraphs 0099 and 0129 is being equated to claim language of being ‘in a list of approved pluggable hardware modules configured to physically attach to the server via the particular externally-accessible slot of the enclosure of the server’), obtain a first digital certificate (a first key, as discloses in paragraph 0100) from the first pluggable hardware module (see paragraph 0100, which discloses “for example, the hash generator 212 can receive a first hash computed using session metadata and signed with a first key from the client device 203”), wherein the list of approved pluggable hardware modules configured to attach to the server via the particular externally-accessible slot is included in the metadata (see paragraph 0099, which discloses “the metadata of the session can include a list of users with access or permission to the session”); in response to validating the first digital certificate using a first public key [a first hash; see paragraph 0100, which discloses “the signed first hash can be referred to as a token (e.g., a first token)”] associated with the first pluggable hardware module, wherein the first public key is included in the metadata (see paragraph 0100, which discloses “the hash generator 212 can receive the session metadata as a separate data packet from the client device 203 or extract the session metadata from the first hash”), enable a first program running within a first virtual machine launched at the server to access application data of the first application from the first pluggable hardware module, wherein the application data of the first application is generated at least in part by the first auxiliary processor [see paragraph 0102, which discloses “if they are matched, the session manager 216 can accept the session registration request (e.g., to send or receive streams for a particular session) from the client device 203. If not matched, the session manager 216 can reject the session registration request. One or more users can register for the session to receive or transmit feeds within the session” and paragraph 0151]; in response to detecting that the first pluggable hardware module has been detached from the server while the server remains powered on, save state information of the first application [see paragraph 0092, which discloses “the media content 234 data storage can include, store, or maintain media content streamed, broadcasted, or shared by devices in all breakout sessions, such as audio feeds, video feeds, screen share feeds, whiteboard feeds, text or drawings provided to the whiteboard by one or more users, among other data received from the user. The media content can be referred to as media stream. Each media content can be labeled with at least timestamps, session identifier (e.g., which breakout session the content is being distributed to), account identifier (e.g., account providing the content), device identifier (e.g., device used to access the account permitted to provide the content), file type (e.g., audio or video), among others. The media content can be distributed among users within a session, such as to provide audio or video feeds to participants. The media content can be provided to an administrator device existing outside of the session”]; detect that the second pluggable hardware module has been attached to the server via the particular externally-accessible slot (see paragraphs 0097 and 0098); in response to determining that the second pluggable hardware module is in the list of approved pluggable hardware modules (see paragraph 0099, which discloses “the metadata of the session can include a list of users with access or permission to the session”), obtain a second digital certificate (a first key of a second client 102, as discloses in paragraph 0100) from the second pluggable hardware module (see paragraph 0100, which discloses “for example, the hash generator 212 can receive a first hash computed using session metadata and signed with a first key from the client device 203”), and in response to validating the second digital certificate using a second public key [a first hash of a second client 102; see paragraph 0100, which discloses “the signed first hash can be referred to as a token (e.g., a first token)”] associated with the second pluggable hardware module, wherein the second public key is included in the metadata (see paragraph 0100, which discloses “the hash generator 212 can receive the session metadata as a separate data packet from the client device 203 or extract the session metadata from the first hash”), enable a second program running within a second virtual machine launched at the server to access application data of the second application from the second pluggable hardware module, wherein the application data of the second application is generated at least in part by the second auxiliary processor [see paragraph 0102, which discloses “if they are matched, the session manager 216 can accept the session registration request (e.g., to send or receive streams for a particular session) from the client device 203. If not matched, the session manager 216 can reject the session registration request. One or more users can register for the session to receive or transmit feeds within the session” and paragraph 0151].
3. As per claims 2, 7 and 17, Asgekar discloses “The system as recited in claim 1” [See rejection to claim 1 above], wherein the memory stores further program instructions that when executed on the primary processor: launch (note, the word ‘launch’ is being interpreted as to use/run) the first virtual machine after validating the first digital certificate (see paragraph 0036).
4. As per claims 3, 8 and 18, Asgekar discloses wherein the memory stores further program instructions that when executed on the primary processor: launch the first virtual machine at the server using a machine image associated with the first pluggable hardware module, wherein the machine image is included in the metadata [see paragraph 0099, which discloses “the metadata can include other information related to the session, such as a maximum number of participants per session (e.g., max number of participants in the session), the appearance of the session interface (e.g., texts and images), bandwidth threshold allocated for the session, among other information or data in the background of the session”].
5. As per claims 4, 9 and 19, Asgekar discloses wherein the memory stores further program instructions that when executed on the primary processor: obtain, from the metadata, module mounting configuration information for the first pluggable hardware module, wherein the first program running within the first virtual machine is enabled to access the application data using the module mounting configuration information (see paragraph 0099).
6. As per claims 5, 14 and 20, Asgekar discloses wherein the first application comprises one of: (a) a radio-based communication network (see paragraph 0070), (b) an application for analysis of signals received from Internet-of-Things sensors, (c) an application which executes a machine learning model, or (d) an application which executes a task of a search-and-rescue operation.
7. As per claim 10, Asgekar discloses wherein the metadata is stored at the first server in encrypted form, the computer-implemented method further comprising: obtaining, at the first server, a server-specific cryptographic key via another programmatic interface; and decrypting the metadata using the server-specific cryptographic key (see abstract of Asgekar).
8. As per claim 11, Asgekar discloses, further comprising: generating a copy of the metadata in response to input received via another programmatic interface; storing the copy at a second server; and utilizing the copy at the second server to enable a second application to be executed at the second server using a second pluggable hardware module (see paragraph 0138, which discloses “the “Metadata” can include additional information on the whiteboard, such as questions attached to a frame, images on the whiteboard, background of the whiteboard, among other configurations on the whiteboard editable by the host sharing the whiteboard” and paragraph 0098, which discloses “the interface 208 can transmit individual whiteboards to student devices, such that each student device can be presented with a copy of a whiteboard. Each participant using a student device can edit or draw on their respective whiteboard, which can be shared with the educator”).
9. As per claim 12, Asgekar discloses, further comprising: deleting, from the first server after execution of the first application has been terminated at the first server, a portion of the metadata in response to input received via another programmatic interface, wherein the deleted portion of the metadata pertains to the first pluggable hardware module; and determining, in response to a detection of attachment of the first pluggable hardware module after the portion of the metadata has been deleted, that the first pluggable hardware module can no longer be used to run the first application at the first server (see paragraphs 0098 and 0138).
10. As per claim 13, Asgekar discloses, further comprising: presenting, in response to input received via another programmatic interface, an indication of the group of approved pluggable hardware modules (see paragraphs 0098 and 0138).
11. As per claim 15, Asgekar discloses, wherein the enclosure comprises a second slot for attaching the one or more types of pluggable hardware modules, the computer-implemented method further comprising: executing a second application at the first server during a time period in which the first application is run at the first server using at least the first pluggable hardware module attached via the first slot, wherein the second application is run at the first server using a second pluggable hardware module attached to the first server via the second slot (see paragraphs 0097, 0098 and 0098, which teach multiple devices/users/participants being connected concurrently).
CLOSING COMMENTS
Conclusion
a. STATUS OF CLAIMS IN THE APPLICATION
The following is a summary of the treatment and status of all claims in the application as recommended by M.P.E.P. 707.07(i):
a(1) CLAIMS REJECTED IN THE APPLICATION
Per the instant office action, claims 1-20 have received a final action on the merits.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
b. DIRECTION OF FUTURE CORRESPONDENCES
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ernest Unelus whose telephone number is (571) 272-8596. The examiner can normally be reached on Monday to Friday 9:00 AM to 5:00 PM.
IMPORTANT NOTE
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner's supervisor, Mr. Idriss Alrobaye, can be reached at the following telephone number: Area Code (571) 270-1023.
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://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/Ernest Unelus/
Primary Examiner
Art Unit 2181
Prosecution Insights