DETAILED ACTION
This Office Action is in response to claims filed on 02/24/2026.
Claims 2 and 4-9 are pending.
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
Applicant’s arguments, see page 7 of applicant's remarks, filed 02/24/2026, with respect to objections to the drawings in view of claims 2-6, and 8-9 have been fully considered and are persuasive. The objection of 12/04/2025 has been withdrawn.
Applicant’s arguments, see page 8-9 of applicant's remarks, filed 02/24/2026, with respect to 112(a) and 112(b) rejection in view of 112(f) claim interpretation of claims 2, 4, 7, and 8 have been fully considered and are persuasive. The rejections of 12/04/2025 has been withdrawn.
Applicant’s arguments with respect to claim(s) 2, 4, 7, and 8 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 112
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.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
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 of carrying out his invention.
Claims 2 and 4-7 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, 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, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim“load, from a library file corresponding to a manufacturer, device-specific API definition information” and “invoke, based on the loaded device-specific API definition information”. Further, each claim recites “read, using the loaded device-specific API definition information” and “call, using the loaded device-specific API definition information, a device-specific API function to” across multiple limitations. Examiner is unable to find support for the claim language in the specification. The Examiner has considered the disclosure at [0061] of the instant specification, which recites “In this embodiment, the APP requests a series of specific callback functions (submodules corresponding to functions) from one library file module each time the APP loads the library file module.” While the instant specification discloses loading “specific callback functions” from a library file module, the instant specification is silent on the claimed limitations using “device-specific API definition information”. Thus, claims 2 and 4 are rejected under 35 U.S.C. 112(a).
Claims 5-6 are dependent on claim 4 and fail to cure the deficiencies set forth above for claim 4. Therefore, they are additionally rejected under the same rationale discussed above.
Claim 7 is an independent system claim that recites “the library file module according to claim 2 to:”, and fails to cure the deficiencies set forth above for claim 2. Therefore, the claim is additional rejected under the same rationale discussed above.
Claim Rejections - 35 USC § 112
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2 and 4-7 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The following claim language is unclear:
With regard to claim 2, lines 5-6, recites “load, from a library file corresponding to a manufacturer, device specific application programing interface (API) definition information”. It is unclear from the context of the claim to ascertain the structure or device that is performing the load function as recited in the claim. More particularly, it is unclear whether the loading is performed by the device executing the application or the multi-adapter compatibility device.
Additionally claim 2, lines 10-11, recites “invoke, based on the loaded device-specific API definition information, device-specific API functions to perform the device operations”. Similar to rationale set forth above, it is unclear from the context of the claim to ascertain the structure or device that is performing the invoke function as recited in the claim.
Claim 4 is a computer-implemented method claim having similar limitation as claim 2 above. Therefore, it is rejected under the same rationale discussed above.
Claims 5-6 are dependent on claim 4 and fail to cure the deficiencies set forth above for claim 4. Therefore, they are additionally rejected under the same rationale discussed above.
Claim 7 is an independent system claim reciting “the library file module according to claim 2 to:”, and fails to cure the deficiencies set forth above for claim 2. Therefore, the claim is additional rejected under the same rationale discussed above.
Claim 2 recites the limitation "wherein invoking the device-specific API functions comprises calling the API to cause the device to perform the device operations" in lines 11-12. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Microsoft Corporation "The Component Object Model: Technical Overview" (hereinafter Microsoft) in view of Burke et al. Patent Number 5,327,558 (hereinafter Burke).
With regard to claim 2, Microsoft teaches a library file module for multi-adapter compatibility (Pg. 1, The Component Object Model (COM) is a software architecture that allows applications to be built from binary software components. COM is the underlying architecture that forms the foundation for high-level software services, like those provided by OLE.), wherein the library file module is stored on a non-transitory computer-readable medium and comprises executable instructions that, when executed by a processor (Pg. 3, For any given platform (hardware and operating system combination), COM defines a standard way to lay out virtual function tables (vtables) in memory, and a standard way to call functions through vtables (Examiner notes: Thus, COM is implemented as a non-transitory computer-readable medium within memory and executed on a processor).), cause the processor to:
load, from a library file corresponding to a manufacturer, device-specific application programming interface (API) definition information (Pg. 3, To clarify: In COM, an object is a piece of compiled code that provides some service to the rest of the system; Pg. 8, The COM Library is a system component that provides the mechanics of COM … Typically, when an application creates a COM component, it passes the CLSID of the COM component class to the COM library. The COM library uses that CLSID to look up the associated server code in the registration database. If the server is an executable, COM launches the EXE and waits for it to register its class factory through a call to CoRegisterClassFactory) that describes callable device functions (Pg. 3, In COM, applications interact with each other and with the system through collections of functions called interfaces … An interface is the definition of an expected behavior and expected responsibilities) and device-defined physical channel attributes), wherein loading the device-specific API definition information comprises reading the API definition information without executing device operations (Pg. 7, QueryInterface is the mechanism that allows clients to dynamically discover (at run time) whether or not an interface is supported by a COM component; at the same time, it is the mechanism that a client uses to get an interface pointer from a COM component. When an application wants to use some function of a COM component, it calls that object’s QueryInterface, requesting a pointer to the interface that implements the desired function.);
invoke, based on the loaded device-specific API definition information (Pg. 8, COM uses the object’s IClassFactory to ask the class factory to create an instance of the COM component, and sends a pointer to the requested interface back to the calling applications.), device-specific API functions to perform the device operations (Figure 2, Virtual function tables link provisioned VTBL pointer to associated function; Figure 7, Clients always call-in process code; Pg. 11, COM components are always called by in-process code. COM provides the underlying transparent RPC.), wherein invoking the device-specific API functions comprises calling the API to cause the device to perform the device operations (Pg. 3, For any given platform (hardware and operating system combination), COM defines a standard way to layout virtual function tables (vtables) in memory, and a standard way to call functions through vtables. Thus, any language that can call functions via pointers … all can be used to write components that can interoperate with other components written to the same binary standard; Pg. 3, COM components always access other COM components through interface pointers. This is a primary architectural feature of the Component Object Model, because it allows COM to completely preserve encapsulation of a data and processing, a fundamental requirement of a true component software standard; Pg. 4, In COM, the client can only call methods of the interface to which it has a pointer.);
However, Microsoft does not explicitly teach the particular submodules comprised within a library file module.
Burke teaches wherein the executable instructions further cause the processor to:
device-specific application programming interface (API) definition information that describes … device-defined physical channel attributes (Col. 17, In order to enable multiple applications 20, 22 to share a single Shared Data Communication Device 30 (FIG. 5), the invention has identified each application’s communication “channel” as a session.)
…
read, using the load device-specific API definition information, a serial number of the device and return the serial number of the device to an application (APP) (Col. 10, The pseudo-code listing for FIG. 7 comprises a procedure call-tree for the routine PERFORM THE SESSION MANAGER START UP 202. The procedure PERFROM THE SESSION EAGER START UP 202 calls the sub-procedures … GET HARDWARE INFORMATION 214; Col. 11, The pseudo-code listing for FIG. 9 comprises a procedure call-tree for routine GET HARDWARE INFORMATION 214. The procedure GET HARDWARE IFNROMATION 214 calls routines GET MEMORY INFORMATION 232, GET DISPLAY ADAPTER INFORMATION 234, GET PC TYPE 235, and GET COMM PORT INFORMATION 236 (Examiner notes: which comprises receiving identification of a device within a session);
read, using the loaded device-specific API definition information, a quantity of physical channels of the device and return the quantity of physical channels of the device to the APP (Col 14, The routine GET COMM PORT ADDRESSES 272 (FIG. 12) retrieves the standard DOS COM Port 101 (FIG. 5) addresses … GET COMM PORT ADDRESSES [A] : COM1, COM2, etc.);
read, using the loaded device-specific API definition information, a type and a baud rate of a specific physical channel of the device and return the type and the baud rate of the device to the APP (Fig. 12, 273 Get Communication Port Configuration; Col. 14, The routine GET COMM PORT CONFIGURATION 273 (FIG. 12,) retrieves the configuration (e.g., baud rate, parity, stop bits) for each port and stores it in memory, RAM 8 (FIG. 2). (Examiner notes: such that the routine returns both a channel type attributes and that channel’s baud rate); Col. 13, The pseudo-code listing for FIG. 12 comprises a procedure call-tree for the routine GET COMM PORT INFORMATION 236 … GET COMM PORT CONFIGURATION [B]: Baud rate, stop bit, parity, etc. (Examiner notes: substantially received for all port addresses);
call, using the loaded device-specific API definition information, a device-specific API function to write a given baud rate of the APP into the specific physical channel of the device (Col. 17, The expanded pseudo-code listing for enable SERIAL PORT INT’s HANDLED BY THE SERIAL PORT EAGER TASK 312 is shown … Initialize the serial port settings all the related parameters (baud, parity, stop bits etc.).);
call, using the loaded device-specific API definition information, a device specific API function to connect the APP and the device (Col. 22, The pseudo-code listing for OPEN SESSION 332 (FIG. 17) is shown … Open an application’s session and mark it active, Allocate and initiate session queues and Return a session handle);
call, using the loaded device-specific API definition information, a device specific API function to obtain messages read by the device from all of the physical channels of the device (Col. 23, The pseudo-code listing for GET MESSAGE 336 (FIG. 17) is shown … Get a message (if one exists) from the proper session’s queue (i.e., a message or response), Copy the message to application’s data buffer allocated by the application, Discard message from the local queues) and return the messages to the APP (Col. 22 - Col. 23, The pseudo-code listing for SEND MESSAGE 335 (FIG. 17) is shown … Get a data buffer to be sent as a message, Copy the data buffer content into a local data buffer, Store the message in the proper session’s queue according to priority); and
call, using the loaded device-specific API definition information, a device specific API function to disconnect the APP from the device (Col. 23, The pseudo-code listing for CLOSE SESSION 333 (FIG. 17) is shown … Use a session handle to mark the session suspended, Keep handling session queues and inbound (received) messages … The pseudo-code listing for DELETE SESSION 334 (FIG. 17) is shown … Identify session by its handle and mark it deleted, Empty all session queues and deallocate queue’s memory).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Burke with the teachings of Microsoft in order to provide a computer-readable medium that teaches loading and invocation of specified functions of a registered component through a unifying software architecture framework. The motivation for applying Burke teaching with Microsoft teaching is to provide a computer-readable medium that allows for the use of known methods directed to communication establishment and shutdown, message receiving and transmitting, channel configuration including quantity, type, and baud rate and device identification with known methods of loading and invoking vendor-specific API information under a unifying software framework in order to yield predictable results of interoperability across vendor-specific devices. Microsoft and Burke are analogous art directed towards interprogram communication. Therefore, it would have been obvious for one of ordinary skill in the art to combine Burke with Microsoft to teach the claimed invention in order to provide a standard for component interoperability that enable the definition, communication, and execution of particular vendor-specific functions of a component to separate components within the system.
Claims 4-7 are rejected under 35 U.S.C. 103 as being unpatentable over Microsoft Corporation "The Component Object Model: Technical Overview" (hereinafter Microsoft) in view of Burke et al. Patent Number 5,327,558 (hereinafter Burke) in view of White et al. Patent No. US 7,370,335 B1 (hereinafter White).
White was cited in IDS filed 09 May 2025.
With regard to claim 4, Microsoft teaches a calling method for multi-adapter computability, comprising:
building a library file module (Pg. 1, The Component Object Model (COM) is a software architecture that allows applications to be built from binary software components. COM is the underlying architecture that forms the foundation for high-level software services, like those provided by OLE) for a manufacturer (Pg. 1, These services provide distinctly different functionality to the user. However, they share a fundamental requirement for a mechanism that allows binary software components, derived from any combination of pre-existing customers’ components and components from different software vendors, to connect to and communicate with each other in a well-defined manner. This mechanism is supplied by COM, a software architecture);
…
wherein the library file module is stored on a non-transitory computer-readable medium and comprises executable instructions that, when executed by a processor (Pg. 3, For any given platform (hardware and operating system combination), COM defines a standard way to lay out virtual function tables (vtables) in memory, and a standard way to call functions through vtables (Examiner notes: Thus, COM is implemented as a non-transitory computer-readable medium within memory and executed on a processor).), cause the processor to:
load, from a library file corresponding to a manufacturer, device-specific application programming interface (API) definition information (Pg. 3, To clarify: In COM, an object is a piece of compiled code that provides some service to the rest of the system; Pg. 8, The COM Library is a system component that provides the mechanics of COM … Typically, when an application creates a COM component, it passes the CLSID of the COM component class to the COM library. The COM library uses that CLSID to look up the associated server code in the registration database. If the server is an executable, COM launches the EXE and waits for it to register its class factory through a call to CoRegisterClassFactory) that describes callable device functions (Pg. 3, In COM, applications interact with each other and with the system through collections of functions called interfaces … An interface is the definition of an expected behavior and expected responsibilities) and device-defined physical channel attributes, wherein loading the device-specific API definition information comprises reading the API definition information without executing device operations (Pg. 7, QueryInterface is the mechanism that allows clients to dynamically discover (at run time) whether or not an interface is supported by a COM component; at the same time, it is the mechanism that a client uses to get an interface pointer from a COM component. When an application wants to use some function of a COM component, it calls that object’s QueryInterface, requesting a pointer to the interface that implements the desired function.);
invoke, based on the loaded device-specific API definition information (Pg. 8, COM uses the object’s IClassFactory to ask the class factory to create an instance of the COM component, and sends a pointer to the requested interface back to the calling applications.), device-specific API functions to perform the device operations (Figure 2, Virtual function tables link provisioned VTBL pointer to associated function; Figure 7, Clients always call-in process code; Pg. 11, COM components are always called by in-process code. COM provides the underlying transparent RPC.), wherein invoking the device-specific API functions comprises calling the API to cause the device to perform the device operations (Pg. 3, For any given platform (hardware and operating system combination), COM defines a standard way to layout virtual function tables (vtables) in memory, and a standard way to call functions through vtables. Thus, any language that can call functions via pointers … all can be used to write components that can interoperate with other components written to the same binary standard; Pg. 3, COM components always access other COM components through interface pointers. This is a primary architectural feature of the Component Object Model, because it allows COM to completely preserve encapsulation of a data and processing, a fundamental requirement of a true component software standard; Pg. 4, In COM, the client can only call methods of the interface to which it has a pointer.);
However, Microsoft does not explicitly teach the particular submodules comprised within a library file module.
Burke teaches wherein the executable instructions further cause the processor to:
device-specific application programming interface (API) definition information that describes … device-defined physical channel attributes (Col. 17, In order to enable multiple applications 20, 22 to share a single Shared Data Communication Device 30 (FIG. 5), the invention has identified each application’s communication “channel” as a session.)
…
read, using the load device-specific API definition information, a serial number of the device and return the serial number of the device to an application (APP) (Col. 10, The pseudo-code listing for FIG. 7 comprises a procedure call-tree for the routine PERFORM THE SESSION MANAGER START UP 202. The procedure PERFROM THE SESSION EAGER START UP 202 calls the sub-procedures … GET HARDWARE INFORMATION 214; Col. 11, The pseudo-code listing for FIG. 9 comprises a procedure call-tree for routine GET HARDWARE INFORMATION 214. The procedure GET HARDWARE IFNROMATION 214 calls routines GET MEMORY INFORMATION 232, GET DISPLAY ADAPTER INFORMATION 234, GET PC TYPE 235, and GET COMM PORT INFORMATION 236 (Examiner notes: which comprises receiving identification of a device within a session);
read, using the loaded device-specific API definition information, a quantity of physical channels of the device and return the quantity of physical channels of the device to the APP (Col 14, The routine GET COMM PORT ADDRESSES 272 (FIG. 12) retrieves the standard DOS COM Port 101 (FIG. 5) addresses … GET COMM PORT ADDRESSES [A] : COM1, COM2, etc.);
read, using the loaded device-specific API definition information, a type and a baud rate of a specific physical channel of the device and return the type and the baud rate of the device to the APP (Fig. 12, 273 Get Communication Port Configuration; Col. 14, The routine GET COMM PORT CONFIGURATION 273 (FIG. 12,) retrieves the configuration (e.g., baud rate, parity, stop bits) for each port and stores it in memory, RAM 8 (FIG. 2). (Examiner notes: such that the routine returns both a channel type attributes and that channel’s baud rate); Col. 13, The pseudo-code listing for FIG. 12 comprises a procedure call-tree for the routine GET COMM PORT INFORMATION 236 … GET COMM PORT CONFIGURATION [B]: Baud rate, stop bit, parity, etc. (Examiner notes: substantially received for all port addresses);
call, using the loaded device-specific API definition information, a device-specific API function to write a given baud rate of the APP into the specific physical channel of the device (Col. 17, The expanded pseudo-code listing for enable SERIAL PORT INT’s HANDLED BY THE SERIAL PORT EAGER TASK 312 is shown … Initialize the serial port settings all the related parameters (baud, parity, stop bits etc.).);
call, using the loaded device-specific API definition information, a device specific API function to connect the APP and the device (Col. 22, The pseudo-code listing for OPEN SESSION 332 (FIG. 17) is shown … Open an application’s session and mark it active, Allocate and initiate session queues and Return a session handle);
call, using the loaded device-specific API definition information, a device specific API function to obtain messages read by the device from all of the physical channels of the device (Col. 23, The pseudo-code listing for GET MESSAGE 336 (FIG. 17) is shown … Get a message (if one exists) from the proper session’s queue (i.e., a message or response), Copy the message to application’s data buffer allocated by the application, Discard message from the local queues) and return the messages to the APP (Col. 22 - Col. 23, The pseudo-code listing for SEND MESSAGE 335 (FIG. 17) is shown … Get a data buffer to be sent as a message, Copy the data buffer content into a local data buffer, Store the message in the proper session’s queue according to priority); and
call, using the loaded device-specific API definition information, a device specific API function to disconnect the APP from the device (Col. 23, The pseudo-code listing for CLOSE SESSION 333 (FIG. 17) is shown … Use a session handle to mark the session suspended, Keep handling session queues and inbound (received) messages … The pseudo-code listing for DELETE SESSION 334 (FIG. 17) is shown … Identify session by its handle and mark it deleted, Empty all session queues and deallocate queue’s memory).
Rationale to claim 2 applied here.
However, Microsoft and Burke do not explicitly teach the obtaining of message information of a device by an application using the library file and disconnecting the device after obtaining the message information.
White teaches obtaining, by an application (APP), message information of a device by using the library file module (Col. 23-Col. 24, When an application (e.g., application 362) makes a workflow request/call/command, the request/call/command can be communicated to public API layer 350 that operates on the generic objects maintained at that layer (e.g., the objects to the Reference Model). At public API layer 350, the WfProcessMgr can forward the request/command/call to the appropriate adapter in adapter layer 330 for the appropriate running process instance represented by the WfProcessMgr object at public API layer 350. The adapter at adapter layer 330 (E.g., adapter 332) can conform a command/request/call to the native language for the workflow engine’s specific API in workflow engine API layer 320 (i.e., can translate the call received from public API layer 350 into the syntax employed by the workflow engine API 322).); and
disconnecting the device after obtaining the message information (Col. 17, void complete() - can complete the activity (Examiner notes: no further execution is performed); Col. 24, The workflow engine associated with workflow engine API 322 (e.g., workflow engine 312) can the process the call/command/request by retrieving or otherwise manipulating content items from persistent storage 370, or by otherwise manipulating content. The results returned by workflow engine 312 can similarly be mapped to generic results usable by one or more of the generic objects of public API 350 via adapter 332)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of White with the teachings of Microsoft and Burke in order to provide a method that teaches application communication of obtaining message information and disconnecting after obtaining the message information. The motivation for applying White teaching with Microsoft and Burke teaching is to provide the known method of disconnecting a device connection after obtaining message information in combination with the method of invoking a device-specific API operation of a particular device to yield the predictable result of freeing of device interface resources and reducing device contention with reasonable expectation of success. Microsoft and Burke and White are analogous art directed towards interprogram communication. Therefore, it would have been obvious for one of ordinary skill in the art to combine White with Microsoft and Burke to teach the claimed invention in order to provide the known method of device communication of obtaining message information and disconnecting the device connection after obtaining message information.
With regard to claim 5, the combination teaches the calling method for multi-adapter compatibility according to claim 4,
White further teaches wherein the method further comprising:
obtaining, by the APP, the message information of the device by using the library file module corresponding to the manufacturer (Col. 23-Col. 24, When an application (e.g., application 362) makes a workflow request/call/command, the request/call/command can be communicated to public API layer 350 that operates on the generic objects maintained at that layer (e.g., the objects to the Reference Model). At public API layer 350, the WfProcessMgr can forward the request/command/call to the appropriate adapter in adapter layer 330 for the appropriate running process instance represented by the WfProcessMgr object at public API layer 350. The adapter at adapter layer 330 (E.g., adapter 332) can conform a command/request/call to the native language for the workflow engine’s specific API in workflow engine API layer 320 (i.e., can translate the call received from public API layer 350 into the syntax employed by the workflow engine API 322).), and
However, White and Microsoft do not explicitly teach the implementation of the particular function submodules.
Burke teaches sequentially implementing functions (Col. 10, The pseudo code listing for FIG. 7 comprises a procedure call-tree for the routine PERFORM THE SESSION MANAGER START UP 202) of the serial number reading submodule (Col. 8, The pseudo-code listing for FIG. 6, a procedure call tree for the routine HANDLE SESSION MANAGEMENT 201, contains an implementation in pseudo-code of a preferred embodiment of the present invention. The procedure HANDLE SESSION MANAGEMENT 201 calls one or more of the sub-procedures, PERFORM THE SESSION EAGER START UP 202), the channel quantity reading submodule (Fig. 12, 272 Get Communication Port Addresses SESS_MGRACEA; Col 14, The routine GET COMM PORT ADDRESSES 272 (FIG. 12) retrieves the standard DOS COM Port 101 (FIG. 5) addresses (Examiner notes: such that specifies the quantity of open channels), the channel type reading submodule, the channel baud rate reading submodule (Fig. 12, 273 Get Communication Port Configuration; Col. 14, The routine GET COMM PORT CONFIGURATION 273 (FIG. 12,) retrieves the configuration (e.g., baud rate, parity, stop bits) for each port and stores it in memory, RAM 8 (FIG. 2). (Examiner notes: such that the routine returns both a channel type and that channel’s baud rate), the channel baud rate writing submodule (Col. 17, The expanded pseudo-code listing for enable SERIAL PORT INT’s HANDLED BY THE S$ERIAL PORT EAGER TASK 312 is shown), the connection submodule (Fig. 17, 332 Open Session SESS_MGREAA; Col. 22, The pseudo-code listing for OPEN SESSION 332 (FIG. 17) is shown below.), the message sending submodule (Fig. 17, 335 Send Message SESS_MGREAD; Col. 22 - Col.23, The pseudo-code listing for SEND MESSAGE 335 (FIG. 17) is shown below.), the message receiving submodule (Fig. 17, 336 Get Message SESS_MGREAE; Col.23, The pseudo-code listing for GET MESSAGE 335 (FIG. 17) is shown below.), and the disconnection submodule (Fig. 17, 333 Close Session SESS_MGREAB and 334 Delete Session SESS_MGREAC; Col. 23, The pseudo-code listing for CLOSE SESSION 333 (FIG. 17) is shown below … The pseudo-code listing for DELETE SESSION 334 (FIG. 17) is shown below.) to obtain the message information (Col. 8, Regarding FIG. 5 now, the message manager 43 comprises Receive Task 107 and a Transmit Task 108. The Receive Task 107 retrieves data from the Device Manager 48 and routes the data to the in-bound message queue 109-110 or the in-bound message response queue 111-112 of the Device Manager 48.).
Rationale to claim 4 applied here.
With regard to claim 6, the combination teaches the calling method for multi-adapter compatibility according to claim 5,
White further teaches wherein the disconnecting of the device after obtaining the message information (Col. 17, void complete() - can complete the activity; Col. 24, The workflow engine associated with workflow engine API 322 (e.g., workflow engine 312) can the process the call/command/request by retrieving or otherwise manipulating content items from persistent storage 370, or by otherwise manipulating content. The results returned by workflow engine 312 can similarly be mapped to generic results usable by one or more of the generic objects of public API 350 via adapter 332) comprises:
However, White and Microsoft do not explicitly teach device disconnection occurring using the disconnection submodule after obtaining message information.
Burke teaches disconnecting the APP from the device by using the disconnection submodule after obtaining the message information (Col. 17-Col. 20, The pseudo-code listing for HANDLE INBOUND MESSAGES 203 (FIG. 6) is shown below. When the scheduler interrupt is received, the routine begins execution. If at any point the routine “exits”, execution stops until the next scheduler interrupt is received … The current session is set to the next session in the cycle, the serial COM port 101 (FIG. 5) is made available, and the routine exits, until the next scheduler interrupt occurs)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Burke with the teachings of Microsoft and White in order to provide an apparatus that teaches application communication disconnection using the disconnection submodule after obtaining the message information. The motivation for applying Burke teaching with Microsoft and White teaching is to provide an apparatus that allows for multi-application connections to share a single shared data communication device that serves a channel session, close the session, and iterates for all sessions (Col. 17-Col.18, Burke). Microsoft, White, and Burke are analogous art directed towards interprogram communication. Therefore, it would have been obvious for one of ordinary skill in the art to combine Burke with White to teach the claimed invention in order to provide a disconnection submodule to service sessions of an application to a device upon receiving message information.
With regard to claim 7, Microsoft teaches a calling system for multi-adapter compatibility (Pg. 3, In COM, applications interact with each other and with the system through collections of functions called interfaces. Note that all OLE services are simply COM interfaces. A COM "interface" is a strongly-typed contract between software components to provide a small but useful set of semantically related operations (methods).An interface is the definition of an expected behavior and expected responsibilities.), comprising:
the library file module according to claim 2 (Pg. 1, The Component Object Model (COM) is a software architecture that allows applications to be built from binary software components. COM is the underlying architecture that forms the foundation for high-level software services, like those provided by OLE.) to:
However, Microsoft does not explicitly teach obtaining, by the APP, message information of a device.
White teaches obtain, by the APP, message information of a device by using the library file module (Col. 4, Additionally, embodiments of the present invention can include an API adapter layer to translate instructions (i.e., calls) from public API layer to vendor-specific instructions); and
disconnect the device after the message information is obtained (Col. 17, void complete() - can complete the activity (Examiner notes: no further execution is performed); Col. 24, The workflow engine associated with workflow engine API 322 (e.g., workflow engine 312) can the process the call/command/request by retrieving or otherwise manipulating content items from persistent storage 370, or by otherwise manipulating content. The results returned by workflow engine 312 can similarly be mapped to generic results usable by one or more of the generic objects of public API 350 via adapter 332)
Rationale to claim 4 applied here.
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over White et al. Patent No. US 7,370,335 B1 (hereinafter White) in view of Brother et al. Pub. No. WO 91/11870 (hereinafter Brother).
With regard to claim 8, White teaches a multi-adapter compatibility device, comprising:
a control module, and a plurality of interface modules electrically connected to the control module (Col. 4, Embodiments of the present invention can present a standardized public API that programmers can use to write applications consistent with various underlying workflow engines. One embodiment of the present invention can comprise a public API layer including a number of generic software object representing the functional characteristics common to the underling workflow engines. In other words, the public API layer can act as an abstraction layer for the functionality of specific workflow engines. Additionally, embodiments of the present invention can include an API adapter layer to translate instructions (i.e., calls) from the public API layer to vendor-specific instructions.), wherein
each of the interface modules comprises a physical interface circuit and an electrical connector to connect an adapter (Col. 5, Thus, an adapter can map vendor-specific APIs to the public API; Col. 5, the adapters in the adapter layer can map the generic objects and processes of the public API (i.e., objects based on the Reference Model) to vendor-specific objects and processes; Col. 25, Adapter 332 can translate the call or command into a native call or command for a particular workflow engine 312 via the workflow engine API (e.g., workflow engine API 322).); and
the control module comprises a processor and a memory storing firmware to receive, by using the adapter, message information sent by a device (Col. 25, In operation, public API layer 350 can comprise a generic object model representing a standard interface. When a call/request/command is received from an application (e.g., application 366), public API 350 can forward the call or command to the appropriate adapter in adapter layer 330 … Adapter 332 can also map any response provided by workflow engine 312 to generic objects of public API layer 350).
White reasonably teaches the logical coupling of interface modules to an adapter. However, White does not explicitly teach the interface modules comprising physical circuits electrically coupled to the adapter.
Brother teaches interface modules comprise a physical interface circuit (Pg. 8, Adapter cable 2 also includes an interface circuit 16; Pg. 9, interface circuit 16 converts the standard TTL type signals from communication port 10 of supporting equipment 4 to signals which conform to the standard data interface of external equipment 6.) and an electrical connector to connect an adapter (Pg. 8, As shown in FIG. 1, an interface adapter cable 2 provides a communications link between supporting equipment 4 and external equipment 6. Adapter cable 2 includes a 25-pin connector 8 on one end for connecting adapter cable 2 to a communications port 10 on supporting equipment 4 and it includes it includes a different multi-pin connector 12 on its other end for connecting adapter cable 2 to a different communications port 14 on external equipment 6; Pg. 9, Adapter cable 2 implements both the electrical and the physical signal conversions required for supporting equipment and external equipment 6 to communicate with each other)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Brother with the teachings of White in order to provide a system that teaches a physical interface circuit capable of capable of receiving and transmitting signals physically coupled to a hardware adapter. The motivation for applying Brother teaching with White teaching is to provide a system that allows for the combination of the known method of operating a unifying software architecture framework to provide functionality across vendor-specific devices with the known physical interface circuit and electrical adapter connector elements in order to yield predictable results of interoperability of vendor-specific devices in software and hardware layers. White and Brother are analogous art directed towards interprogram communication between incompatible applications. Therefore, it would have been obvious for one of ordinary skill in the art to combine Brother with White to teach the claimed invention in order to provide software and hardware capabilities of interoperability of vendor-specific devices.
With regard to claim 9, White teaches a multi-adapter compatibility system (Col. 25, FIG. 6 illustrates one embodiment of the system 600 according to the present invention), comprising:
a multi-adapter compatibility device and a host computer (Col. 25, System 600 can comprise of one or more workflow engine servers 601 (e.g., workflow engine server 602, workflow engine server 604, and workflow engine server 606), intermediate server 608, and one or more application servers 609 (e.g., application server 610, and application server 612), wherein
the host computer is configured to receive message information sent by the multi-adapter compatibility device and analyze the message information (Col. 25, In this manner, native objects from various workflow engines can be mapped to a set of generic objects at API layer 350. Consequently, applications can be written for a single API (e.g., Public API 350), can be applied to multiple underlying workflow engines)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 11,074,070 B2
teaches
Abstract, A method is provided for integrating interfaces in software. The method includes incorporating a library to the source file to produce a plurality of adapters and abstractions; compiling the adapters and abstractions in to a digital library; transferring the adapters and abstractions into an application source code; linking the application source code with the library to produce a combination file; and compiling the combination file into an executable application file.
US 2009/0249369 A1
teaches
Abstract, In a module-to-module association support system, a controller asks a management server to create an adaptor for us an intermediary between client module and a service module being a target to be associated with the client module. The management server is provided with a service API definition defining the specification of an API service module, and device ID corresponding thereto. The management server selects the service API definition based on the device ID provided by the controller, and creates the adaptor based on the selected service API definition and the provided client API definition. The resulting adaptor is forwarded to a client.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN A CASTANEDA whose telephone number is (571)272-0465. The examiner can normally be reached Monday-Friday 9:30AM-5:30PM 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, Aimee Li can be reached at (571) 272-4169. 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.
/I.A.C./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights